Demoscene accepted as UNESCO cultural heritage in The Netherlands
demoscene-the-art-of-coding.net
demoscene-the-art-of-coding.net
I remember watching Farbrausch's "fr-08 .the .produkt" [0] when it came out and telling myself "If a computer can do this with 64KB of data, at this speed, my programs should be able to do the same, or at least shall be close". I was forever poisoned at this point, and this simple sentence shaped my whole academic life and career.
[0]: https://www.pouet.net/prod.php?which=1221
P.S.: Rewatching it, again, for the nth time. Hats off to chaos, fiver2, kb, doj, ryg & yoda.
P.P.S: I show people YouTube version of Elevated (https://www.pouet.net/prod.php?which=52938), and ask them to guess the binary size rendering this thing in real time. The answer blows everyone's mind, every time.
The title says 4kb, but I assume it's 4KB, which is impressive but not mind blowing for a procedurally generated landscape.
It might not be the most impressive demo tech-wise, but it's one of the best executed ones, and it matters.
Also it's the second most loved prod in pouet.net, which means something.
So it's either 4kB (4000 bytes) or 4KiB (4096 bytes).
why throughput is bits and storage is bytes I might never understand, probably has something to do with baud
If you like that kind of "compression", I hope you know Linus "lft" Åkesson's "A Mind Is Born": 256 bytes.
Not a knock on demos at all! (the originals handed around on floppy disks also inspired me to become a coder in the early 90s). Just saying that it's different to try to make the most amazing thing you can in a wide open 4k than it is to start with something 16k and try to reduce it.
Hence the bunny quotes. Not really «mak[ing] something extremely small», the idea is to pack as much wonder value as achievable in as as little resources as possible.
You can use 'compress', as long as the need to interpret as needed is held - the term is legitimate for the idea of e.g. "pressing together" what would normally be the content of a wardrobe in a suitcase.
https://www.youtube.com/watch?v=m7iuFVmTJus
>You can take any piece of content in the game, and imagine an algorithmic solution to it. Or also, you know, a way that the player could customize that object of thing.
>There's this group in Europe called the Demoscene that make these very elaborate demos for a computer that fit into very tiny little memory blocks, you know like 64K of memory, and you run the thing, and in fact it algorithmically generates about 100 megabytes worth of data, you know these rich 3D environment, generated music, generated wave files, generated animation.
>And they're developing techniques to generate, you know, huge amounts of interesting data, with very very simple, elegant, compression algorithms.
>And this is a skill that game developers used to have, back in the 8-bit days. That was the only ways to do a game like Karateka(?), was to find all these little tips and tricks to compress things and generate them algorithmically.
>But since the CD-ROM came out, and very cheap hard drives, storage is cheap, so basically we've lost that skill set, and now we attack all those problems with brute force. I think we've lost something by dropping that skill set.
The Future of Content — Will Wright’s Spore Demo at GDC 3/11/2005: What I learned about content from the Sims. …and why it’s driven me to procedural methods. …And what I now plan to do with them. Talk by Will Wright, Game Developers Conference, 3/11/2005.
https://donhopkins.medium.com/the-future-of-content-will-wri...
>Algorithmic compression.
>Games consist of a mix of code and data. Computers use code to compress data. The ratio of code to data has changed over time.
>Games used to be mostly code and very little content, so compression was important.
>CDROM is the medium that was the death knell for the algorithm.
>Myst was a very elaborate and beautiful slide show, with a vast amount of data. It looked like they had a great time building this world. Building the world is a fun game in itself.
>At the other end of the spectrum from CDROMs: The Demo Scene. Algorithmic compression of graphics and music.
Will Wright GDC 2005 Spore (The Future of Content) Remastered: 6:18
More info in the extended cut starting at this timestamp: https://youtu.be/5qxg0ykOcgM?t=3465
The costs now run the other way, in fact. If you viewed the main benefit of procedural systems as compression, you're much better off saving the compute cost and just pre-generating and streaming terabytes worth of game assets. (Arguably, Spore could have even benefited from such an approach). The lasting benefit of the procedural is that whoever plays it gets a truly unique experience that no one has seen before, or will see again.
This turned out to impose a hefty 20% CPU drain on the entire game, dragging down the frame rate. It was my own design decision and I argued that 20% was worth it (and that by the time the game was released, CPU speeds would have at least quadrupled), but digging my heels in on the issue of not pre-rendering assets was most of how I ended up leaving the project.
So that's why I would (emotionally, maybe) argue that compression has little to do with decisions to generate things procedurally, since compression was not a goal whatsoever, although the speed penalty was as if a large amount of compression needed to be overcome.
Being able to fit a program that generates lots of content on a small floppy disk or cdrom is one goal, less important today, but the important part is that thinking of procedural content generation as decompression of noise (random, user generated, contextual, or environmental) is a useful technique even with today's virtually unlimited storage and high speed delivery.
Will speaks about compression in information theoretic and arithmetic coding terms, not just referring to standard compression algorithms like "jpeg" or "mp3", but to information encoding and decoding theory, using compression techniques for procedural generation, like LLMs.
Here's a great video of Will Wright and Brian Eno discussing generative systems and demonstrating cellular automata with Mirek's Cellebration to Brian Eno's generative music, at a talk at the Long Now Foundation,:
Will Wright and Brian Eno - Generative Systems (excepts from talk):
https://www.youtube.com/watch?v=UqzVSvqXJYg
>Game designer Will Wright and musician Brian Eno discuss the generative systems used in their respective creative works. This clip features original music by Brian Eno. Will Wright and Brian Eno on "Playing with Time." In a dazzling duet Will Wright and Brian Eno give an intense clinic on the joys and techniques of "generative" creation.
Playing with Time | Brian Eno and Will Wright (entire talk):
https://www.youtube.com/watch?v=Dfc-DQorohc
>Will Wright, creator of the video games "Sim City," "The Sims," and the forthcoming "Spore," will speak on playing with time. "Playing with Time" was given on June 26, 02006 as part of Long Now's Seminar series.
Generative Music – Brian Eno (1996) (inmotionmagazine.com):
https://inmotionmagazine.com/eno1.html
https://news.ycombinator.com/item?id=24702201
Sandspiel Studio, Brian Eno, Wave Function Collapse, visual programming, cellular automata, etc:
https://news.ycombinator.com/item?id=34561910
Here's a simple low-tech pre-LLM example that shows the equivalence of compression and procedural content generation:
Take a huge text file of HN postings, and compress it with gzip or compress or some other robust compression algorithm. The better the algorithm, the more the output will look like random noise. Then slice the compressed file in half, and replace the second half with random numbers. Then uncompress it. You'll find that at the point you sliced it, it keeps on writing out almost plausible text for a while, consisting of highly probably snippets of commonly encountered words and phrases, then goes downhill towards incoherence. It's not as coherent or confident as an LLM, but the point is to show how low the bar is for using compression for procedural content generation.
LLMs are essentially a form of compression of the world's knowledge or whatever they're trained on, not just word frequencies or pixel patterns, but also concepts and ideas.
Ed Fredkin described John Cocke's Theory of Dreams, which describes dreams as a kind of procedural content generation based on running your brain's decoder over random noise inputs:
https://news.ycombinator.com/item?id=36597206
DonHopkins 1 day ago | parent | context | favorite | on: No one cares about your dreams unless you’re a fam...
ON THE SOUL: Ed Fredkin, Unpublished Manuscript
http://www.digitalphilosophy.org/wp-content/uploads/2015/07/
>The John Cocke Theory of Dreams was told to me, on the phone, late one night back in the early 1960’s. John’s complete description was contained in a very short conversation approximately as follows:
>“Hey Ed. You know about optimal encoding, right?”
>“Yup.”
>“Say the way we remember things is using a lossy optimal encoding scheme; you’d get efficient use of memory, huh?”
>“Uh huh.” “Well the decoding could take into account recent memories and sensory inputs, like sounds being heard, right?”
>“Sure!”
>“Well, if when you’re asleep, the decoder is decoding random bits (digital noise) mixed in with a few sensory inputs and taking into account recent memories and stuff like that, the output of the decoder would be a dream; huh?”
>I was stunned.
I found a video of an excellent interview Ed Fredkin in 1990 in which he explains John Cocke's Theory of Dreams in detail, beginning at 18:39, which I'll transcribe because it's so interesting and hasn't been published elsewhere (so now people and LLMs will be able to find it and learn from it too, and dream on, or even compress it, slice it in half, add noise, and decompress it to see what happens):
Ed Fredkin Talks About John Cocke - 4 May 1990: Theory of Dreams
https://youtu.be/DLCb1UV5bzU?t=1119
>I remember one time John called me up to tell me his theory of dreams. And when he first told me this, I thought, boy there's a strange theory if I ever heard one. But I have been interested in what he told me ever since. And this has to be -- it's hard for me to tell you how long ago, but it's 20, 25 years ago.
>And I'm now convinced that his theory of dreams is correct, and it's the only correct theory of dreams. And as near as I know, I don't know anyone who knows it, other than him and whoever else he's told, like me.
>But it's a beautiful theory, and it takes into account, it's really a theory based on what might be called, I wouldn't really call it information theory, but sort of information science. The knowledge we have about information, and how things are coded, and how things can be interpreted, I mean interpreted in a sort of technical computer sense.
>What his theory was, as is typical, I believe this theory was told to me in the middle of the night. But John described the following concept. Imaging the way our memories work is that they're efficient. What's known from information theory is that if you have taken some set of information and attempted to encode it in the most efficient way, then if you have succeeded, then the bits you get from your encoding scheme are indistinguishable from a random sequence of bits.
>And the reason for that is very simple thing: if the bits came out all like this: 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1, then obviously it could have been encoded much more efficiently. You could say there's five 1's in a row, then five... You know, in other words, if there's all kinds of patterns to it, then it can be reduced in size by being further encoded.
>So this is a hallmark from information science of something that has been well encoded, compressed, or condensed. If the brain worked efficiently, then the following thing is true: That the things that go into our memory, if you could look into them with some kind of magic magnifying glass, like the developer they put on magnetic tape to see the actual magnetic signals, would look random.
>Ok, so that's an interesting thought. That's just applying the ideas from information theory and computer science to what might go into your brain.
>But then what John did is he took sort of an amazing leap, and asked the reverse question, which was: If you took a truly random sequence, and fed it into the decoder, what would you get?
>This is a very interesting question, because what that says is say I remember an experience I had. The experience was that I went somewhere, I went on a vacation, I went to a lake, I got a sailboat, I sailed around, there was a thunderstorm, I came back. Say I have some kind of thing like that.
>This is all compacted into these random bits. When they're interpreted, the mind has a decoding scheme, is the idea. So to be efficient, it would have to refer to a logical sequence of things. By that I mean, if it says "I went to a lake, and then I did..." Well what should happen is, the choices are: you went swimming, you went boating, you went sailing, you know.
>There's only a small number of choices, it's not an infinite number. So if you only have a small number like 5, 1 through 5, then 1 might mean I went sailing, 2 might... so on.
>So those things have to do with what is possible, and what's possible for you, and has to do with your other memories, and so on.
>So suddenly John asks the question: What if I fed in a truly random sequence of bits to the decoder? What would you get?
>Well the answers is: you would get a completely plausible sequence of events, since each choice as interpreting them is only selected from plausible events that have to do with you, but it wouldn't correspond to anything in the big story.
>And in fact, it would manufacture a dream!
>So the ideas is that if the source of the information is random noise, but it's fed into the memory decoding mechanism that works efficiently, then what you get exactly matches what a dream is!
>I think this is a very significant discovery of his, and in other words, to me it's about as important as any psychological theory I've ever seen. It makes all of the Freudian analysis of dreams fall into a totally different perspective, where what you learn is what were the categories that might have been selected that have to do with personality. But which ones were ends up just being some random noise, or something like that.
>So to me it fits in with every aspect of dreams. For instance, when you're dreaming, and something happens in the real world, like the telephone is ringing. This stimulus is often encoded in your dream. You dream that there's a phone ringing, and so on and so forth.
>Well, that works perfectly with this scheme, because if there's a phone ringing in your ears hearing it, then it becomes one of the logical things to be tapped by whatever number comes up. The only question is which context it is.
>If there is a phone ringing, the next thought has to be there's a phone ringing. But the random number tells you there's a phone ringing, and you're going to ignore it because someone else is going to answer, or various thing like that.
>So my own -- having thought about this for the maybe 20 years since I heard about, I've concluded that this is the best work on the subject that's been done on the subject that's been done so far by anyone. And I know it's not published or anything, and I'm convinced that it's a great thing. Someone ought to write it up. Or John should. That's the theory of dreams.
I posted more about Ed Fredkin recently in the discussion of his recent passing:
https://news.ycombinator.com/item?id=36429420
https://en.wikipedia.org/wiki/Edward_Fredkin
Here's another great example of applying information theory and compression techniques to efficient text entry, called "Dasher", invented by David MacKay -- think of Dasher as extremely efficiently decompressing cursor motion (or other device inputs) into text:
Dasher: information-efficient text entry
https://www.youtube.com/watch?v=ie9Se7FneXE
>Google Tech Talks, April 19, 2007
>ABSTRACT: Keyboards are inefficient for two reasons: they do not exploit the redundancy in normal language; and they waste the fine analogue capabilities of the user's motor system (fingers and eyes, for example). I describe a system intended to rectify both these inefficiencies. Dasher is a text-entry system in which a language model plays an integral role, and it's driven by continuous gestures. Users can achieve single-finger writing speeds of 35 words per minute and hands-free writing speeds of 25 words per minute. Dasher is free software, and it works in all languages, and on many platforms. Dasher is part of Debian, and there's even a little java version for your web-browser.
Finally, here's an interesting HN discussion about LLMs as data compression, and some interesting replies:
Ask HN: What are the data compression characteristics of LLMs?
https://news.ycombinator.com/item?id=35130027
Ask HN: DietaryNonsense 3 months ago | hide | past | favorite | 3 comments
Disclaimer: I have only shallow knowledge of LLMs and machine learning algorithms and architecture in general.
Once a model has been trained, the totality of it's knowledge is presumably encoded in it's weights, architecture, hyper-parameters, and so on. The size of all of this presumably being measurable in terms of number of bits. Accepting that the total "useful information" encoded may come with caveats about how to effectively query the model, in principal it seems like we can measure the amount of useful information that's encoded and retrievable from the model.
I do sense a challenge in equating the "raw" and "useful" forms of information in this context. An English, text-only wikipedia article about "Shitake Mushrooms" may be 30kb but we could imagine that not all of that needs to be encoded in an LLM that accurately encodes the "useful information" about Shitake mushrooms. The LLM might be able to reproduce all the facts about Shitakes that the article contained but not be able to reproduce the article itself. So in some ontologically sensitive way, the LLM performs a lossy transformation during the learning and encoding process.
I'm wondering what we know about the data storage characteristics of the useful information encoded by a given model. Is there a way in which we can measure or estimate the amount of useful information encoded by a LLM? If some LLM is trained on Wikipedia, what is the relationship between the amount of useful information it can reliably reproduce versus the size of the model relative to the source material?
In the case of the model being substantially larger than the source, can I feel metaphorically justified in likening the model to being both "tables and indices"? If the model is smaller than the source, can I feel justified in wrapping the whole operation in a "this is fancy compression" metaphor?
jeremysalwen 3 months ago | next [–]
Generative models (like LLMs) that assign probabilities to pieces of data are equivalent to compression algorithms.
To convert a generative model into a compression algorithm, you just use arithmetic coding: https://en.wikipedia.org/wiki/Arithmetic_coding.
To convert a compression algorithm into a generative model, you assign a probability to each piece of data according to the size of its compressed representation.
See also the Hutter Prize and associated FAQ: http://prize.hutter1.net/
If you wanted to specifically measure the "useful" information, you would need to have some way of sampling from the set of possible articles that contain the same "useful" information, but vary in the "useless" information, and vice versa. I think you would find that it would be difficult for you to define what the boundary is, but if you made some arbitrary choice, you could measure what you are looking for through the LLM probabilities.
PaulHoule 3 months ago | prev | next [–]
See
https://en.wikipedia.org/wiki/Hutter_Prize
GPT-3 is said to have 175 billion parameters, if those are float32s (I bet they could get away with less than that) it would be 700 GB of data. It's also said in Wikipedia that "60% percent of the weighted pre-training dataset for GPT-3 comes from a filtered version of Common Crawl consisting of 410 billion byte-pair-encoded tokens"
That would be about 680B tokens, say the average token is 5 characters, that is 3400B characters of text, such that the output is "compressed" to 20% of the input, which state-of-the-art text compressors can accomplish.
Now my figures could be off, namely they might be coding the parameters more efficiently and the average token could be longer. But it seems to make sense that if you trained a model to capture as much information as you could possibly capture out of the text it would be that size. Given that that kind of model seems to be able to spit out what it was trained on (though sometimes garbled) that might be about right.
wmf 3 months ago | prev [–]
NNCP: Lossless Data Compression with Neural Networks:
----
Procedural Content Generation: An Overview: Gillian Smith:
http://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter40_Pro...
>One of the first examples of PCG was in the game Elite [Braben 84], where entire galaxies were generated by the computer so that there could be an expansive universe for players to explore without running afoul of memory requirements. However, unlike most modern games that incorporate PCG, Elite’s content generation was entirely deterministic, allowing the designers to have complete control over the resulting experience. In other words, Elite is really a game where PCG is used as a form of data compression. This tradition is continued in demoscenes, such as .kkrieger [.theprodukkt 04], which have the goal of maximizing the complexity of interactive scenes with a minimal code footprint. However, this is no longer the major goal for PCG systems.
>Regardless of whether creation is deterministic, one of the main tensions when creating a game with PCG is retaining some amount of control over the final product. It can be tempting to use PCG in a game because of a desire to reduce the authoring burden or make up for missing expertise—for example, a small indie team wanting to make a game with a massive world may choose to use PCG to avoid needing to painstakingly hand-author that world. But while it is relatively simple to create a system that can generate highly varied content, the challenge comes in ensuring the content’s quality and ability to meet the needs of the game.
He cited it as the line that likewise instigated an irreversible tectonic shift in his own approach to the craft of writing. It was simply this: the realization that "poetry is compression."
I think this insight has stood up to the rise of technological leverage and may generalize extraordinarily well into some sort of philosophical ground truth, on the suspicion that given the mismatch between the scale of the universe and the two-odd kilogram lump of tissue in our skull, all of human knowledge is essentially an exercise in curated compression.
This demo is more on the side of "do magic and observe output", rather than "let's make something looking normal in an impossible way" (i.e: elevated) or "let's make something impossible possible" (i.e. 8088 MPH [0]).
All three kinds are equally impressive in my book, yet I prefer the latter ones more.
My main takeaway from Demoscene is not "compression", but the possibility of writing code which performs very well, and what I found is, it's not very hard to do at the end of the day. You just have to be mindful about what you're doing, and how that thing called computer works under the hood.
This 100%. It's not exclusive to demoscene, but demoscene is certainly yet another inspiration to write lean apps. (The performance of Electron is another :) )
I'll never ever be able to work for an AAA game company because I couldn't stomach dumping 100GB of raw texture data onto someone's hard drive.
Compression is still a big part of it, just not in the "take the original data, minimize it and reproduce it later" sense of the word. The procedural generation employed by these demos is still a form of compression: the highly-specialized decompressor needs only a few bytes of information to create the intended effect (texture or shape).
If anything, it shows how much compression can be achieved if the decompressor can be tuned to the data domain, as opposed to general-purpose compression algorithms.
In the case of the Farbrausch procedural generation, a chaining of parametrized modules creates the textures etc. - as those who have played with their generation system, ".werkkzeug", know directly ( .werkkzeug1, 2004: https://www.pouet.net/prod.php?which=12511 ; .werkkzeug4, 2019? : https://www.pouet.net/prod_nfo.php?which=91144 )
In the case of flt's "A mind is born", several efficiency techniques are used - overlapping of palette and SID registers etc., but especially notable could be that the melody is generated by a sequence-after-seed process (Linear-Feedback Shift Register), where the seed is chosen so that a good melody is returned ( full explanation of the code: https://linusakesson.net/scene/a-mind-is-born/ )
I've seen movie CG that looks way way shittier, that's ten years newer.
The GPU powered demos are impressive in a different way.
One interesting VGA hardware effect in this context which I have not seen in any demo, is to change the character width from 8 to 9 pixels _during_ a horizontal scanline. The trick is to use RDTSC to estimate the pixel position, with which you can create a nice wobble effect in text mode. Obviously, this requires a Pentium or higher, and at the time this became possible, text mode was rather outdated.
Anecdotally, my Pentium 3 machine (forgot what GPU it had, sadly) back in 2004 was struggling with most modern (for the time period) games that had even a hint of graphical fidelity. Max Payne 2, on the other hand, looked mindblowing and ran like butter.
And don’t forget scream tracker 3 ! ( which is actually how I discovered the demoscene)
Clearly there was a little more space they could have eeked out!
Considering ZIP normally uses deflate, which is LZ77 + huffman. LZ77 is super simple and can be implemented in ~30 bytes of code. Huffman tables are fairly simple, but I can't easily visualize some assembly instructions to implement them, however arithmetic coding in all cases exceeds huffman's performance, and can be implemented in about 60 bytes of code. Total = 90 bytes to save 2 kilobytes. Seems worth it.
Note that both these decompressors will be awfully slow, but for just 64 kilobytes of input data I don't think that'll be an issue.
Demoscene stuff is fun, and cool, but it's a hobby. It doesn't reflect how software is developed and deployed in the real world.
You're right, when developing a product, the goal is to deliver the product and value, however a programmer who likes their job doesn't develop products all the time, they also improve themselves.
What I found is, studying "The Machine" and its details, and trying to write exceptional code, improves the "daily, mundane" code, too. Because you know what to do, and how to do it better.
In other words, if Demoscene is F1 racing, and you have the chops to design vehicles which can compete there, the technology you develop trickles down to your road-going designs, and improve them, too.
While I was writing my Ph.D. code, knowing the peculiarities of the machine allowed me to write very efficient and fast code in the first go, and the code can saturate the machine it's running on extremely well. To put in context, I was able to evaluate 1.7 million adaptive Gaussian integrations per second, per (3rd generation Intel i7) core. That code scales almost linearly until memory controller chokes because of the traffic (incidentally this happens after I saturate all the cores).
This code has no special optimizations. A single, naive, multithreaded implementation which I spent half a day designing it, that's all. There are all kinds of optimizations I can do to speed this a bit further, but since it's fast enough, I didn't bother.
At the end of the day, I'm an HPC sysadmin and developer. I inhale hardware and exhale performance. While there's a value to be delivered, it's extreme speed in my case. Because that speed saves days in research time, not milliseconds.
A rubbish hammer may be e.g. «useful» for some dozen bangs in a few weeks, then crumble. A rubbish item will have compromises. A "good" product will be masterful and optimal for function, less compromising for the demanding user.
This marked the genesis of my coding journey, igniting a lifelong passion for programming that endures still, spanning several decades in the tech landscape.
A highlight, to this day, involved creating and releasing our Amiga Demo-Creator in May 1987:
https://coding-and-computers.blogspot.com/2022/05/first-amig...
I've always been amazed at the sheer skill and creativity of the programmers in this subculture, to the point where I consider them to be in an entirely different league from the "regular" programmer building web, desktop, mobile and enterprise apps using some high-level language, of which I'm humbly a part of. Demo programmers can seemingly control electrons at their will, and mostly do so for fun and pleasure, whereas we work with layers and layers of abstractions and mostly for compensation. I'm not saying that the world doesn't need both, just that one is more aligned to that child-like curiosity and wonder at making lights blink, taken to an extreme level, which is IMO a purer reason to love computers.
The demoscene always did sit in a weird intersection between technology and art, and the roots and association with piracy (that often in the beginning in large parts were teenage ganglike groups) did add a distinct "harshly" competitive edge you don't see in other art perhaps with the exception of hiphop.
However, 2 factors is changing things out to a mellower experience, one is that people have grown older and there's probably a realization for many who still participate about our mortality as people literally start to die off and few fresh faces appear.
The other is that the workload to make code that could be impressive has risen and with hardware getting faster without changing much the pure rendering quality of what pre-made engines like Unity and Unreal can accomplish (or tools like Notch, whilst being demoscene rooted still is a commercial product today). SDF's gave the scene productions an edge in achieving cool stuff for a bunch of years (still beneficial for size) but usage is spreading quickly in games today. This might be part of why many seem to have taken "refuge" in working on retro-demos since squeezing cool stuff out of old machines isn't directly comparable to what people working full time on games,etc can achieve.
As for what you can learn, yes, it's plenty of greenfield programming but "maintenance programming" gets boring quite quickly as well unless you work for a hyperscaler and/or a startup.
Also, browsers are no less general purpose computers than physical computers are. There's nothing you can compute in one that you can't compute on the other.
1. There's no software specifically developed for webassembly, unlike for x86, ARM, and the other architectures.
2. Webassembly itself was designed by software people, not hardware people. As such, it's probably doesn't make as much sense to implement directly in hardware. Doubly so when combined with reason #1.
3. Webassembly doesn't belong to any hardware manufacturer, and therefore nobody has any incentive to introduce a line of native webassembly machines.
It features programming in multiple languages: cobol, fortran, lua, pascal, ruby, vala, ada, d, java, objc, scheme, visualbasic, asm, javascript, ocaml, python, shell
Big shame no videos of it are up on the internet anymore, I've looked quite hard, but nothing. The code is available here however: https://launchpad.net/binaryofbabel/+download
My mom (krentewegge) and myself (demoscene) are equally thrilled.
Yeah, right, let's just ignore panettone exists for a moment.
I have good information that the best panettone could be at the Pasticceria Roletti, in San Giorgio Canavese, in northern Piedmont.
I remember going to copy parties from The Raven (1992?), cycling 10 km with ~100 floppy discs, wondering whether some bit would shake off whenever I hit a bump in the road.
I still get goosebumps when I think of the time when some guy from a nearby city demoed his own Adlib player and 60fps flat shading 3d renderer!
Meeting people in person to share code (or to keep it secret), reading paper magazines (Dr Dobbs) buying books on holidays (PC Intern anyone?, Ferraro, Foley), ah those were the days :)
Still on my bookshelf. Also Messmer (The Indispensable PC Hardware Book) and ofcourse the Abrash books.
The late 80s & early 90s where a great time growing up in The Netherlands if you were a computer/pc nerd. :)
So many demos, groups, parties and people to mention, so head over to any of these sites:
Luckily never got caught ;-)
Based on the YT comments it's been done at shadertoy too: https://www.shadertoy.com/view/XdsGWH
[1]: http://pouet.net/prod.php?which=4662 [2]: https://youtu.be/_zSjpIyMt0k
It’s just internet points I guess, except not with points and not on the internet.
I organized a few demoparties back in the day and it’s really just, rent a place where loud music is ok, get people to come. Lots to plan and arrange ofc, but nothing that needs permission or money from bobos.
Maybe the bigger parties like Revision can use this to get permits etc but I think all things considered it won’t have a major impact on anything tangible. It’s just cool, recognition.
"Yeah but which officials?"
School rectors for example. Local mayors. The types who can give access to big rooms, you can rent for free, if what you do is considered "cultural".
(but yes, there is the danger of doing it all very tame then)
Just kidding, I have no idea :)
I've loved the demoscene on the Amiga and Atari ST sonce the 1980s and have started attending demoparties sonce last year. I have great respect for the efforts of the folks ar Art of Coding and their friends in the different countries. To achieve this sort of UNESCO legitimation is an amazing achievement that takes a lot of serious work and persuasion.
My most sincere thanks and admiration to the Art of Coding folks and to DigitalKultur.
What does it actually achieve, concretely? I get listing a historical building to preserve and maybe drive some tourism, but these sorts of intangible things... what is the real world result?
He meant that he wanted to build something that took time and care, but it would last and amaze all who saw it with its beauty and impressive construction.
I showed him 8088MPH, which took seven years to write: https://m.youtube.com/watch?v=yHXx3orN35Y
He said "OK, that's the Sagrada Família of software."
Thinking on the Matrix sequels which, I know, do not exist, I came to a stunning realization: The Machines have a demoscene. Neo encounters a pair of programs who are trying to smuggle their daughter, Sati, into the Matrix. The Oracle told Neo that every program in the Matrix has a purpose, but Sati does not and that's why she is at risk of deletion. Her parents created her simply to experience the joy of loving her.
Sati is a demo. Like any demo she exists simply to delight her creators and anyone who observes her. We even get to see a demoeffect of hers: the colorful sunrise she creates for Neo to enjoy, wherever he may be. This demonstrates that the Machines have developed art, empathy, and love, quite possibly due to Neo's influence.
Cracktros and their music are also worth preserving. Razor and such. There are many vintage ones for DOS, Windows, Amiga, Mac, and probably others. I'm sure they're difficult to find and some maybe lost.
I couldn't find it on unesco.nl because everything is in Dutch.
Well-cared-for in that they captured from original hardware, took scanlines, refresh rate, etc into consideration.
I had read about perlin noise but never truly appreciated it until I saw some of the demoscene demos.
Everything - the music, the landscape, trees, cameras, buildings - all procedurally generated. Code is maximally reused.
Made me think, perhaps the brain is also doing that. Just storing symbols and rough descriptions, enough to recognize it again and reason/imagine the world. But high compressed lossy model of the world. Perhaps the brain is just a few gigabytes of memory to restore someone’s consciousness. May be less.
demoscene does that to you.
Even just guidelines on the entire compilation step would be appreciated, or knowledge on how some fairly standard examples of demos were compiled, and which tools were used.
The main ingredient of the secret sauce is a special compressing linker, called crinkler.
Dont forget that most democoders want to make stuff. Something like Visual Studio, which you can (pirate and) install, and then you type code and press a button with a play icon and see the code run, that’s super nice and it’s had that UX for 20 years or so.
Compared to Linux at the time, which drew the kinds of people who enjoyed building up their perfect Gentoo from scratch and setting up their Vim just right, and making automake detect dependencies on all the distros. To your average demoscener, all that stuff gets in the way of getting graphics on the screen.
These days the difference is pretty much gone though, so it’s just momentum. You can install Ubuntu and a random IDE and code some opengl in an SDL window and things will Just Work just like they would on Windows. And I assume even Linux these days has a way to deal with dependencies that’s as easy for devs as Windows’s “just add the DLLs you need to the zip file”.
Also since intros were size-limited you kinda needed control of your pipeline to achieve the smallest size of the _binary_. For a 4k intro different compilers could produce different sized binaries, the .exe compressor crinkler mentioned above does some "function-order-randomization" to improve compression by a few bytes by having the correct ordering of data/functions so just running a slightly different version and/or not long enough could fail to produce something below 4k.
I got out of the demo scene after the Commodore 64, but isn't the whole point that it's supposed to be hard, not easy? That's what makes it amazing.
At the risk of sounding dismissive, Linux was for the kinds people who enjoyed configuring stuff, digging through man pages, editing textfiles and then recompiling their kernels. It was for people who loved tuning their system 100% perfectly to their needs. Not for people who just wanted to code cool computer art.
Actually I think most democoders, even the insanely good ones, have very little patience. The attractive thing about coding graphics is the dopamine cycle is short. It's code, run, woa cool!, code, run, woa cool!.
For demos the social aspect is important and one thing Windows is good at is that you have good chance of being able to run random exe you downloaded, which is far less a given with Linux and especially with 3d graphics and audio
Flatpak might now represent the sort of platform that could be good enough, but really the best would be to have something similar but more minimal and specifically designed for demos; I'm thinking some kind of sandbox that would run single elf executable and expose just enough primitives (mesa, wayland, pipewire, glibc) to make democoding feasible and would give fair even ground for sizecoding.
Code was often kept secret, to add to the mysticism of the amazing algorithms (which often turned out to be very clever tricks, and not academic breakthroughs), or to simply hide the fact that the code was a terrible mess.
With regards to Linux -- Avoozl and I wrote a 4k intro for it in 1999 [1]. It was quite a lot of effort, with custom ELF headers to shave off a few bytes. There were but few people willing to run the thing as root though. (This was a requirement for svgalib, and us demosceners couldn't understand why unix sysadmins took offence with that :)
If anyone manages to turn it into a YouTube video, I will, ehm, applaud them for it!
Most are 4k exegfx, which means they are still images, but "scalemark" is an animated 4k intro with music.
Some demos I liked watching are tens of megabytes, e.g. https://www.pouet.net/prod.php?which=57446 . I'm not sure why that still counts as a demo, but I suppose as long as the the sequence of things is mostly driven by code, then it does. Perhaps it's like 500kB of custom stuff glued onto a 42MB off-the-shelf game engine like Unity, which I think should be totally okay to count as a demo. Obviously this won't be competing in any size category.
https://www.pouet.net/prod.php?which=5
(I have to admit I probably turned the text off though...)
[0] http://www.textfiles.com/programming/astrainer.txt
(key quote:)
[ There they sit, the preschooler class encircling their
mentor, the substitute teacher.
"Now class, today we will talk about what you want to be
when you grow up. Isn't that fun?" The teacher looks
around and spots the child, silent, apart from the others
and deep in thought. "Jonny, why don't you start?" she
encourages him.
Jonny looks around, confused, his train of thought
disrupted. He collects himself, and stares at the teacher
with a steady eye. "I want to code demos," he says,
his words becoming stronger and more confidant as he
speaks. "I want to write something that will change
peoples perception of reality. I want them to walk
away from the computer dazed, unsure of their footing
and eyesight. I want to write something that will
reach out of the screen and grab them, making
heartbeats and breathing slow to almost a halt. I want
to write something that, when it is finished, they
are reluctant to leave, knowing that nothing they
experience that day will be quite as real, as
insightful, as good. I want to write demos."
Silence. The class and the teacher stare at Jonny, stunned. It
is the teachers turn to be confused. Jonny blushes,
feeling that something more is required. "Either that
or I want to be a fireman."
]Thats amazing and also kinda wtf because drunken parties are the norm, so cultural alcoholism is a bonus.
So much that now, it is most often used sarcastically, like when a new group releases something cool.
The state of the art has also been progressing. Some of the things coded on the C64 these days are things that I found too difficult to do on the Amiga back in the '90s when I was active.
That energy is dead and gone. Once something hangs in a museum, its still art, but it is no longer alive, no longer evolving and becoming.
But don't underestimate the energy of nostalgia. It's still there and, AFAIC, the scene and I : until death us do part !