I understand that it might be nice to be able to play old demos in your browser, and its fine, but...
Please keep AI away from the demoscene.
Ive been active in the demoscene for almost 30 years, its a big part of my life, and i am truly worried people using AI to build tools and code demos will destroy it by removing the very reason why its interesting. I want to be impressed by real peoples knowledge, skill and creativity. Not your ability to prompt.
Mostly, i hate the AI remaster option. It was never intended to look or sound like that.
People still use old platforms without GPUs. It's a completely different art form. On a modern PC with a GPU you can render anything you want because it was solved years ago.
Its about people doing the seemingly impossible with technology, not technology doing whats possible with technology. If you use AI, you did nothing but ask it, and i could never be impressed by that.
And how would you vote in the competitions at demoparties? By tokens used?
Most parties strictly forbid the use of AI in production, but im afraid some people aren't honest enough to abide to that rule.
Yes, but “doing” with AI is not actually doing it, is it? Yes, something gets done, but the end result was never the point of the demoscene. The finished product was merely the proof-of-work.
From discussing with demosceners I think people pretty unanimously agree vibecoded prods are lame, if sometimes fun. There's nothing impressive about a vibecoded demo, and even if they are visually impressive, that isn't really the point. The point is that people actually made it, the demo itself is an artifact of the talent of the group that made it. If anything it's a bit awkward when people submit heavily vibecoded demos.
Yes demoscene is about doing the impossible with Technology, but its also about proving that your group is good at performing miracles with computers. Modern demos are still technically impressive, but art direction is much more important for a high-tier demo. It's not "we are doing this impressive thing" as much as it is "Look what WE are able to do with this technical trick we are harnessing". The group and people behind the demo is a brand and part of the experience.
My personal opinion is that if you think a 100% vibecoded demo is cool, you don't really "get" the demoscene. Nobody is impressed that you could vibecode a visually impressive demo. You aren't winning anyone's respect. Nobody will work to beat you (they will at best push Claude harder - its a question of money not talent). The point of the demoscene is to pull off impressive feats with computer hardware, and if you didn't even do it yourself, nobody cares, because it's not impressive.
I think few are going to hate you for outsourcing basic, repetitive work to an LLM. But if you go "hey claude make me a particle engine" it kind of misses the point?
Then again I'm not really a hardcore scener myself, with just a few mediocre prods, so maybe someone from Farbrausch, ASD, TBL, or others will show up and tell me why I am wrong.
I got my first PC (a 486 DX2-66) in 1994 and got a Creative Soundblaster graphics card + speakers later that year. Second reality was the first demo I had on that PC. I remember being blown away by the graphics and audio... I showed it off to everyone. Of course it looks quite quaint now, but at the time I had just upgraded from a Commodore 64!
Cycle accurate emulation helps little with this era PC demos, because back in 1993 PC hardware performance variation was already massive. From 386SX-16 to Pentium 66 MHz, that's over 20x difference in performance.
> Cycle accurate emulation helps little with this era PC demos, because back in 1993 PC hardware performance variation was already massive.
Absolutely
"How much of the sword emerged from the water" in Second Reality was a good measurement of CPU speed and video card performance, for example.
I remember seeing stuff in demos on my friend's Pentium Pro machine that I never saw on my 486SX-25 because routines ran faster and you could see more of the effect (since some demos were sync'd to the music and would move on irrespective of the progress of the effects). Heck-- just replacing my video card made a huge difference with some demos.
> Cycle accurate emulation helps little with this era PC demos
It works, and has done for some time, surely. What more is there to add here above accurate playback?
> From 386SX-16 to Pentium 66 MHz, that's 10-20x difference in performance.
Yep, and some demos had specific requirements for not only minimal CPU but maximal because the assumptions inherent in small-code timing tricks would break beyond a certain speed or because of significant differences in relative instruction execution times (and sometimes the unpredictability of those execution times as the P5 architecture and some of its frankenstein-486-like competitors added branch prediction). Larger demos were more flexible as you didn't need the small-code tricks to squeeze into 4Kb or sometimes less, so 64K demos and larger could be more flexible wrt target CPU.
But cycle-accurate emulation has this sorted to: you just need the instruction cycle time accuracy to be matching a particular CPU running to the pace of a particular clock. And given the description of how this is being done (“The demo is run on an x86 emulator that records…”) I assume this is actually using cycle-accurate emulation!
I'm guessing the benefit here is that the overhead of playing back the demo on each client machine is lower when playing this recorded version, compared to each viewer's browser running the initial emulation live in the browser. That and doing something a new way was fun or otherwise intellectually stimulating for the dev(s) involved.
> It's funny how LLMs leak their test procedure docs into user-facing output.
You have to constantly fight so hard to not get this. And for the past few months it seems most people do not even care to remove it and have proper user facing docs
> You have to constantly fight so hard to not get this.
By “fight so hard” you mean “do a bit of basic editing before publishing the text”?
You wouldn't have thrown a junior's text straight at end users without any review in the past (at least I hope not, though obviously some teams actually were and still are that lax), why do you expect to get away with skipping the review/edit step with your clockwork colleague?
> What's the advantage of this approach vs cycle-accurate emulation? (I'd guess it can go faster, due to compiler optimization?)
I don't think anyone is doing it this way because they chose to do it this way. All the AI decomp/recomp projects I've seen recently have done it this way. It just seems an easy way to have an AI brute force "port" something.
Yes, cycle-accurate is very expensive because it prevents optimization. But as described they say they're doing an AOT version of cycle-accurate anyway?
In some ways this is similar to the concurrent-systems problems that memory barriers are a tool to address. Your emulator will come in two halves, a CPU side and a gfx/sfx side, as well as control inputs, and the "intermediate" approach is when you're just trying to preserve the sequence of load/stores between the two with an accuracy relative to frame timing. Maintaining ultra precise timing within a frame imposes more detailed coordination requirements on both sides of the emulation.
Being cycle-accurate is annoying when you want full realtime if the hosting platform doesn't have enough CPU power to emulate all parts at full speed.
I guess the point is that a pre-compiled version could have HW checkpoints from a slow emulated run, so that it can then run at full speed and just advance the HW to the required timestate when a write is to occur (ie, instead of costly cycle-accurate emulationg, most HW operations can be batched inbetween time-sensitive checkpoints).
Then again, why not just record a video at that point? :P
The days I gave up with demoscene. When PC killed Atari ST and Amiga scene (sorry to put you after amiguys, but life was always easier for you ;) ), all the magic of fixed hardware without tons of Mhz and RAM, when we were running after that cathode ray which wouldn't wait, exploiting hardware bugs to break those damn borders above, below and sideways, spending hours turning my head upside-down to read unreadable scrolltexts, looking at psychedelic plasma effects with bazillions colors...
Then I betrayed you all: I bought my first ugly machine because of Doom. I was so ashamed...
Now, only 4KB demos can at least impress me a bit.
Running Crystal Dream 2 on a 386 was just as impressive as running those border-removing, cycle-counting C64 demos. Hardware was not fixed on the PC, but upgrades were mostly about improving quality without losing any of the original charm (Gravis Ultrasound FTW!), like a 40MHz 386 was only marginally faster than a 33MHz, and that just allowed you a few more FPS in Doom.
The standard VGA resolution fit a full screen in a single 64KB segment nicely, you had many colors but not limitless, so I would argue that this was really the golden era of the demoscene. Partly because almost anyone could do some kind of a short demo that was still enjoyable to watch, and did not require the insane amount of cycle-counting and optimization and planning that the C64 does.
I gave up once full screen video playback was possible from CD-ROM. After that, doing (typically worse) non-interactive animations in real-time, seemed a bit pointless.
But watching Crystal Dreams II on my phone actually made me feel young again :)
To be specific, the Amiga scene for a good while chased "coolness" with accelerated "monster"-Amigas.
But the focus shifted in recent years to treating "OCS" (ie "standard" Amiga500 with original chipset and 1mb,etc) more like a fixed platform like the C64 instead and imho has seen a bit of a revival since is mostly in the interesting part of pushing the OCS HW.
this is mind boggling! although during the 90s might have started to shift to use C in damascene production, but when I was most active (90-94) we were hand rolling a lot of code in assembly. memory "management" was pretty basic at best, code and data occasionally separated. maybe for demos it was less of thing, but for smaller intros, writing into the code during runtime was maybe not everyday process, but definitely not unheard. some of the graphic modes were barely documented if at all, so get this up and running with this accuracy is pretty remarkable. just some of the code from back then, might not pass a PR review nowadays
Look, I've used trillions times the resources that are needed to run or even to program these demos (which are marvels of the art of coding) to run them in a browser.
And I didn't do any coding to achieve that.
Cool right?
Eh.. no. A completely boring negation of what demos are about.
Checking the site out, I can't help but think its a huge contrast between the modern vibecoded slop with little added value(we already have webassembly DOS emulators!) and the ground-breaking productions made with blood, sweat, and tears 30 years ago. This is to demoscene what gentrification is to neighborhoods.
Lots of talk of DOS, but both games that are described (Panzer General II and Imperialism II) were only released for Windows?
If the games had been for DOS, it would probably have made more sense to just run the original binaries in DOSBox-X or some other emulator. I think there is already some debug API that can be enabled. Or adding MCP or something similar to DOSBox(-X) would probably be a lot less work than to reimplement the games.
Ah, yes, sorry. At this point, XP and DOS are almost synonymous for me.
The entire point of the port was to add headless play for AI training. But porting the old interface and playing it in the browser was lots of fun. Can not upload that to GitHub, obviously.
I find it hard to congratulate someone on a project when they say Claude or whatever did it for them. It just feels so insincere. I myself wouldn't feel good getting compliments about something that I prompted into existence.
It is true what people say wrt using agentic development being like being a manager: you take an idea from elsewhere (a lot of game porting is happening right now), describe it to someone else who will do the hard work while you relax, and then at the end you as the team lead/manager claim all the credit.
The demoscene was all about human ingenuity getting the most out of the machine. It was about showing off how good your crew was at making things from nothing but their minds.
Now, it too, has been swallowed by the AI that is destroying this entire mode of being, the joy and creativity of writing code, of solving seemingly-impossible puzzles with ones mind.
My favorite creative and intellectual outlet is dying off and its killer is wearing its corpse as a costume.
For these four demos I don't know, but part of the challenge was certainly working within the constraints of the machines of the day. The Furture Crew demo I believe comes in at 2.5MB and ran on a 1993 PC, so probably 8MB of ram at the most. Running it in the browser is probably at least 20 times the memory.
It's really cool to be able to rewatch these demo, but the spirit in which they were created is somewhat lost.
I feel the same, it sucks. All you can do is carve out a space for yourself doing the things you enjoy, and don't let the AI grifters tell you that AI is the only way and everyone else is "cooked", no one will be writing things by hand, etc etc. God that rhetoric is depressing.
I write demos and games as a hobby predominantly for MS-DOS and machines ranging from the 386 up to the Pentium (soon to add 8088/286 to that list) as well as old consoles like the Sega Master System and other random platforms (like ARM-based kids toys like the Leapster Explorer).
Right now I'm working on an EGA production. I could just get an AI to generate a lot of the code for me or give me all the answers, but instead, I have my Programmer's Guide to the EGA/VGA/SVGA by Ferraro and another reference open on my desk trying to understand the CRTC so I can create a custom video mode. I live for this stuff and want to fully understand what's going on in the hardware. I like the creative aspects of making demos and games but I also like the technical aspects, and understanding the platform and the deep details.
When I spend too much time reading HN or X and see too much of the AI stuff, it really bums me out, so I have to detox by unfollowing/ignoring and getting back to my projects.
Not sure if this will help, but nothing can take away the enjoyment of investing time in doing something "the hard way" for the sake of it unless you let it. Factories have been able to make good wooden tables efficiently since probably the 1950s, but there are still people who make their own with woodworking tools because they find it satisfying.
I think the biggest effect of AI here is that you can no longer make the inference from "that program looks impressive" to "the person who created it must be very skilful and/or invested a lot of effort in making it". So someone else seeing your work might not appreciate the level of effort and skill you put into it, or might even suspect you of lying if you say explicitly that you made it "by hand". I'm not going to say that we shouldn't care what others think; that's not realistic, most of us do want some recognition for things we've worked hard on. I think there will always be people interested in doing things the hard way, and among those people the "old" paths to recognition and respect still operate, it just gets harder because there has to be a lot of trust between them that no one's taken the easy way out (AI) and pretended otherwise.
The C64 scene is still surprisingly active, and they usually do the seemingly impossible on such a limited hardware, while remaining incredibly creative (in how many ways could you phase out the C64 BASIC screen and show your demo't title?...). After the PC golden era I've been interested in the C64 only for a very, very long time, and I have not regretted it.
You just don't understand, it's the prompt and knowing which foreign work to endless rehash that's the new creativity now. There's taste in knowing what artist to steal from!
Who's going to show up to the next big demo party (like the ones they arrange in Europe), having e.g. hand coded 68k assembly or done some highly impressive 4k demo, having been intimate with every single instruction?
Uh, many people. There are plenty of demo parties with retro categories in the compos, and plenty of people still interested in writing their own code for those platforms.
Maybe it will just pass? Eventually maybe people will get bored of this consumerist mode of creation, of projects born with no vision or craft, made with the tastefulness of a kid smashing together their favorite toys. And when the majority finally agrees these stunts are a corrosive influence on the community, we can just approach it as a moderation problem, figure out some system of vouches and reports, or downsize and our communities until trust again becomes tractable, maybe even coming to appreciate some tactical slop as a stepping stone or a proof of concept to be eventually reverse-engineered into a maintainable human project.
Or an eternal heaven, our every wish coming true. The next iteration of homo sapiens will not be thinking how to do things, but what things to do. Is this the new creative space for us?
What makes you say this? Just because someone used AI to port some classic productions to the browser (which is actually pretty cool), doesn't mean that AI has taken over.
AI slop productions tend to be frowned upon, or even banned, writing code and using cool tricks to to what seems impossible is still a big part of the demoscene, in particular in the sizecoding, oldschool and wild categories. Clever use of AI is a debated topic, the demoscene is about pushing the limits of current technology, and AI is part of current technology. There is also the question of using AI for tooling (modelers, compressors, test harnesses, etc...), as in, will you stop using a particular IDE because it is written with the help of AI, even if it is good?
If there’s no human effort behind this, what’s the point? You could just as well watch any of the zillions of video recordings of these demos. There’s no inherent value in "running natively in the browser". Never mind the vast irony in demoscene specifically being a celebration of human skill and creativity.
Not going to say anything about AI translations. But the video recording don't do justice for many of demos.
The effects in some of the demos simply kill any video encoder, only way to properly experience them is by running or emulating locally. Not that crystal sharp upscaled square pixels on modern display or poor quality CRT filters are very representative either, but it's likely better than blurry mess you get when video encoder tries to deal with high frequency details or random noise from procedural effects.
I must have watched Second Reality almost a hundred times when I was younger. A video does not do it justice. This is the closest you can get on modern hardware.
Well, there is a little advantage. Most recordings are not at the native framerate, and have compression artefacts (which impacts some effects more than others)
Lack of CRT flicker is the biggest problem. Demo text scrolls are far more readable when you don't have sample-and-hold blur. There are gaming monitors with strobed backlights but I don't know of any that allow you to enable the strobing at 70Hz.
A workaround for modern hardware is frame doubling then blanking every other frame (software black frame insertion). It halves the brightness, but modern monitors generally support higher brightness than CRTs so this just brings it back to the authentic level. It's possible with FFMPEG filters, although I don't remember how I accomplished it when I tried it years ago.
The importance of CRT flicker is one reason I greatly prefer DOS demos to C64 and Amiga demos. Those were mostly designed for 50Hz PAL CRTs, so the flicker is far more annoying than 70Hz VGA.
I mean even these browser ports aren't at the native framerate. The native framerate for these demos was 70hz as they were all designed for VGA video modes.
I'm all for this future. Let's remove the tooling and let true creativity and diligence be what we appreciate and marvel at. If we can instruct AI well enough, it can eliminate the plumbing layer entirely, allowing us to focus on what truly matters.
Those demos from the '90s remind me of the incredible creativity and ingenuity of the human mind. Thanks for bringing them back to life and making them so effortlessly accessible.
>Those demos from the '90s remind me of the incredible creativity and ingenuity of the human mind. Thanks for bringing them back to life and making them so effortlessly accessible.
I understand that it might be nice to be able to play old demos in your browser, and its fine, but...
Please keep AI away from the demoscene.
Ive been active in the demoscene for almost 30 years, its a big part of my life, and i am truly worried people using AI to build tools and code demos will destroy it by removing the very reason why its interesting. I want to be impressed by real peoples knowledge, skill and creativity. Not your ability to prompt.
Mostly, i hate the AI remaster option. It was never intended to look or sound like that.
it's as if someone took the "everything you touch turns to gold" and replaced gold with sh*t and said "yeah this is a good power to have"
The reverse Midas touch.
1 reply →
It was similar with GPUs and people got over it. It's all about art and creativity whatever you are using shaders or AI prompts
People still use old platforms without GPUs. It's a completely different art form. On a modern PC with a GPU you can render anything you want because it was solved years ago.
No, its not at all similar. Comparing shader coding with AI prompting is just dumb, sorry.
Why gatekeeping? Demoscene was always about doing the impossible with technology. Technology now is AI.
Demoscene should embrace it.
I think i was pretty clear in my original post.
Its about people doing the seemingly impossible with technology, not technology doing whats possible with technology. If you use AI, you did nothing but ask it, and i could never be impressed by that.
And how would you vote in the competitions at demoparties? By tokens used?
Most parties strictly forbid the use of AI in production, but im afraid some people aren't honest enough to abide to that rule.
4 replies →
> Demoscene was always about doing
Yes, but “doing” with AI is not actually doing it, is it? Yes, something gets done, but the end result was never the point of the demoscene. The finished product was merely the proof-of-work.
From discussing with demosceners I think people pretty unanimously agree vibecoded prods are lame, if sometimes fun. There's nothing impressive about a vibecoded demo, and even if they are visually impressive, that isn't really the point. The point is that people actually made it, the demo itself is an artifact of the talent of the group that made it. If anything it's a bit awkward when people submit heavily vibecoded demos.
Yes demoscene is about doing the impossible with Technology, but its also about proving that your group is good at performing miracles with computers. Modern demos are still technically impressive, but art direction is much more important for a high-tier demo. It's not "we are doing this impressive thing" as much as it is "Look what WE are able to do with this technical trick we are harnessing". The group and people behind the demo is a brand and part of the experience.
My personal opinion is that if you think a 100% vibecoded demo is cool, you don't really "get" the demoscene. Nobody is impressed that you could vibecode a visually impressive demo. You aren't winning anyone's respect. Nobody will work to beat you (they will at best push Claude harder - its a question of money not talent). The point of the demoscene is to pull off impressive feats with computer hardware, and if you didn't even do it yourself, nobody cares, because it's not impressive.
I think few are going to hate you for outsourcing basic, repetitive work to an LLM. But if you go "hey claude make me a particle engine" it kind of misses the point?
Then again I'm not really a hardcore scener myself, with just a few mediocre prods, so maybe someone from Farbrausch, ASD, TBL, or others will show up and tell me why I am wrong.
Wow, this brings back memories!
I got my first PC (a 486 DX2-66) in 1994 and got a Creative Soundblaster graphics card + speakers later that year. Second reality was the first demo I had on that PC. I remember being blown away by the graphics and audio... I showed it off to everyone. Of course it looks quite quaint now, but at the time I had just upgraded from a Commodore 64!
> The demo is run on an x86 emulator that records every block of code the CPU actually executes, over the whole demo.
> That recording is translated into C - the original instructions, one for one, with the exact cycle timing of the emulated machine.
What's the advantage of this approach vs cycle-accurate emulation? (I'd guess it can go faster, due to compiler optimization?)
> The result is checked against the emulator event for event: every interrupt, port access and frame at the same moment of emulated time.
It's funny how LLMs leak their test procedure docs into user-facing output.
Cycle accurate emulation helps little with this era PC demos, because back in 1993 PC hardware performance variation was already massive. From 386SX-16 to Pentium 66 MHz, that's over 20x difference in performance.
> Cycle accurate emulation helps little with this era PC demos, because back in 1993 PC hardware performance variation was already massive.
Absolutely
"How much of the sword emerged from the water" in Second Reality was a good measurement of CPU speed and video card performance, for example.
I remember seeing stuff in demos on my friend's Pentium Pro machine that I never saw on my 486SX-25 because routines ran faster and you could see more of the effect (since some demos were sync'd to the music and would move on irrespective of the progress of the effects). Heck-- just replacing my video card made a huge difference with some demos.
> Cycle accurate emulation helps little with this era PC demos
It works, and has done for some time, surely. What more is there to add here above accurate playback?
> From 386SX-16 to Pentium 66 MHz, that's 10-20x difference in performance.
Yep, and some demos had specific requirements for not only minimal CPU but maximal because the assumptions inherent in small-code timing tricks would break beyond a certain speed or because of significant differences in relative instruction execution times (and sometimes the unpredictability of those execution times as the P5 architecture and some of its frankenstein-486-like competitors added branch prediction). Larger demos were more flexible as you didn't need the small-code tricks to squeeze into 4Kb or sometimes less, so 64K demos and larger could be more flexible wrt target CPU.
But cycle-accurate emulation has this sorted to: you just need the instruction cycle time accuracy to be matching a particular CPU running to the pace of a particular clock. And given the description of how this is being done (“The demo is run on an x86 emulator that records…”) I assume this is actually using cycle-accurate emulation!
I'm guessing the benefit here is that the overhead of playing back the demo on each client machine is lower when playing this recorded version, compared to each viewer's browser running the initial emulation live in the browser. That and doing something a new way was fun or otherwise intellectually stimulating for the dev(s) involved.
1 reply →
> It's funny how LLMs leak their test procedure docs into user-facing output.
You have to constantly fight so hard to not get this. And for the past few months it seems most people do not even care to remove it and have proper user facing docs
> You have to constantly fight so hard to not get this.
By “fight so hard” you mean “do a bit of basic editing before publishing the text”?
You wouldn't have thrown a junior's text straight at end users without any review in the past (at least I hope not, though obviously some teams actually were and still are that lax), why do you expect to get away with skipping the review/edit step with your clockwork colleague?
5 replies →
I didn’t notice it when using Codex. Recently switched to Claude to test Opus 5.5, and it is constantly adding useless commentary.
1 reply →
> What's the advantage of this approach vs cycle-accurate emulation? (I'd guess it can go faster, due to compiler optimization?)
I don't think anyone is doing it this way because they chose to do it this way. All the AI decomp/recomp projects I've seen recently have done it this way. It just seems an easy way to have an AI brute force "port" something.
This only works for something noninteractive that always executes the same code (unless I'm misunderstanding the LLM's description of what it did)
2 replies →
Yes, cycle-accurate is very expensive because it prevents optimization. But as described they say they're doing an AOT version of cycle-accurate anyway?
In some ways this is similar to the concurrent-systems problems that memory barriers are a tool to address. Your emulator will come in two halves, a CPU side and a gfx/sfx side, as well as control inputs, and the "intermediate" approach is when you're just trying to preserve the sequence of load/stores between the two with an accuracy relative to frame timing. Maintaining ultra precise timing within a frame imposes more detailed coordination requirements on both sides of the emulation.
Being cycle-accurate is annoying when you want full realtime if the hosting platform doesn't have enough CPU power to emulate all parts at full speed.
I guess the point is that a pre-compiled version could have HW checkpoints from a slow emulated run, so that it can then run at full speed and just advance the HW to the required timestate when a write is to occur (ie, instead of costly cycle-accurate emulationg, most HW operations can be batched inbetween time-sensitive checkpoints).
Then again, why not just record a video at that point? :P
The days I gave up with demoscene. When PC killed Atari ST and Amiga scene (sorry to put you after amiguys, but life was always easier for you ;) ), all the magic of fixed hardware without tons of Mhz and RAM, when we were running after that cathode ray which wouldn't wait, exploiting hardware bugs to break those damn borders above, below and sideways, spending hours turning my head upside-down to read unreadable scrolltexts, looking at psychedelic plasma effects with bazillions colors...
Then I betrayed you all: I bought my first ugly machine because of Doom. I was so ashamed...
Now, only 4KB demos can at least impress me a bit.
Feeling old.
Running Crystal Dream 2 on a 386 was just as impressive as running those border-removing, cycle-counting C64 demos. Hardware was not fixed on the PC, but upgrades were mostly about improving quality without losing any of the original charm (Gravis Ultrasound FTW!), like a 40MHz 386 was only marginally faster than a 33MHz, and that just allowed you a few more FPS in Doom.
The standard VGA resolution fit a full screen in a single 64KB segment nicely, you had many colors but not limitless, so I would argue that this was really the golden era of the demoscene. Partly because almost anyone could do some kind of a short demo that was still enjoyable to watch, and did not require the insane amount of cycle-counting and optimization and planning that the C64 does.
I gave up once full screen video playback was possible from CD-ROM. After that, doing (typically worse) non-interactive animations in real-time, seemed a bit pointless.
But watching Crystal Dreams II on my phone actually made me feel young again :)
Man, demoscene has always been pointless. That's one of the beauties of the thing, you cannot sell that. I call it love.
The Amiga scene is still popular, probably for the reason you said.
To be specific, the Amiga scene for a good while chased "coolness" with accelerated "monster"-Amigas.
But the focus shifted in recent years to treating "OCS" (ie "standard" Amiga500 with original chipset and 1mb,etc) more like a fixed platform like the C64 instead and imho has seen a bit of a revival since is mostly in the interesting part of pushing the OCS HW.
this is mind boggling! although during the 90s might have started to shift to use C in damascene production, but when I was most active (90-94) we were hand rolling a lot of code in assembly. memory "management" was pretty basic at best, code and data occasionally separated. maybe for demos it was less of thing, but for smaller intros, writing into the code during runtime was maybe not everyday process, but definitely not unheard. some of the graphic modes were barely documented if at all, so get this up and running with this accuracy is pretty remarkable. just some of the code from back then, might not pass a PR review nowadays
Look, I've used trillions times the resources that are needed to run or even to program these demos (which are marvels of the art of coding) to run them in a browser.
And I didn't do any coding to achieve that. Cool right?
Eh.. no. A completely boring negation of what demos are about.
No credits for Trade War 2002 though. See ascii art
a couple of days ago I posted this: https://news.ycombinator.com/item?id=49982323
State of the Art was ported to the browser as well.
Checking the site out, I can't help but think its a huge contrast between the modern vibecoded slop with little added value(we already have webassembly DOS emulators!) and the ground-breaking productions made with blood, sweat, and tears 30 years ago. This is to demoscene what gentrification is to neighborhoods.
So much fun. I recently ported some old strategy games. Claude does it almost on its own http://replicated.live/blog/games
Lots of talk of DOS, but both games that are described (Panzer General II and Imperialism II) were only released for Windows?
If the games had been for DOS, it would probably have made more sense to just run the original binaries in DOSBox-X or some other emulator. I think there is already some debug API that can be enabled. Or adding MCP or something similar to DOSBox(-X) would probably be a lot less work than to reimplement the games.
Ah, yes, sorry. At this point, XP and DOS are almost synonymous for me.
The entire point of the port was to add headless play for AI training. But porting the old interface and playing it in the browser was lots of fun. Can not upload that to GitHub, obviously.
3 replies →
So who or what ported them?
I find it hard to congratulate someone on a project when they say Claude or whatever did it for them. It just feels so insincere. I myself wouldn't feel good getting compliments about something that I prompted into existence.
It is true what people say wrt using agentic development being like being a manager: you take an idea from elsewhere (a lot of game porting is happening right now), describe it to someone else who will do the hard work while you relax, and then at the end you as the team lead/manager claim all the credit.
Opus 5.5.
1 reply →
This kind of made me sad.
The demoscene was all about human ingenuity getting the most out of the machine. It was about showing off how good your crew was at making things from nothing but their minds.
Now, it too, has been swallowed by the AI that is destroying this entire mode of being, the joy and creativity of writing code, of solving seemingly-impossible puzzles with ones mind.
My favorite creative and intellectual outlet is dying off and its killer is wearing its corpse as a costume.
For these four demos I don't know, but part of the challenge was certainly working within the constraints of the machines of the day. The Furture Crew demo I believe comes in at 2.5MB and ran on a 1993 PC, so probably 8MB of ram at the most. Running it in the browser is probably at least 20 times the memory.
It's really cool to be able to rewatch these demo, but the spirit in which they were created is somewhat lost.
Second Reality ran comfortably with only 640KB RAM using the Gravis Ultrasound.
But it did require a 386, which typically had 2 MB or more of RAM back then.
Second Reality runs in real mode, and doesn't use XMS or EMS so it runs in 640kb!
2 replies →
> probably 8MB of ram at the most. Running it in the browser is probably at least 20 times the memory.
lol, that would be 160MB then, a fraction of what a Firefox Tab consumes and in todays hardware specs its a roundoff error :-D
(while back then you were the ultimate king if you had 8 MB of RAM available at all! :-)
I feel the same, it sucks. All you can do is carve out a space for yourself doing the things you enjoy, and don't let the AI grifters tell you that AI is the only way and everyone else is "cooked", no one will be writing things by hand, etc etc. God that rhetoric is depressing.
I write demos and games as a hobby predominantly for MS-DOS and machines ranging from the 386 up to the Pentium (soon to add 8088/286 to that list) as well as old consoles like the Sega Master System and other random platforms (like ARM-based kids toys like the Leapster Explorer).
Right now I'm working on an EGA production. I could just get an AI to generate a lot of the code for me or give me all the answers, but instead, I have my Programmer's Guide to the EGA/VGA/SVGA by Ferraro and another reference open on my desk trying to understand the CRTC so I can create a custom video mode. I live for this stuff and want to fully understand what's going on in the hardware. I like the creative aspects of making demos and games but I also like the technical aspects, and understanding the platform and the deep details.
When I spend too much time reading HN or X and see too much of the AI stuff, it really bums me out, so I have to detox by unfollowing/ignoring and getting back to my projects.
Not sure if this will help, but nothing can take away the enjoyment of investing time in doing something "the hard way" for the sake of it unless you let it. Factories have been able to make good wooden tables efficiently since probably the 1950s, but there are still people who make their own with woodworking tools because they find it satisfying.
I think the biggest effect of AI here is that you can no longer make the inference from "that program looks impressive" to "the person who created it must be very skilful and/or invested a lot of effort in making it". So someone else seeing your work might not appreciate the level of effort and skill you put into it, or might even suspect you of lying if you say explicitly that you made it "by hand". I'm not going to say that we shouldn't care what others think; that's not realistic, most of us do want some recognition for things we've worked hard on. I think there will always be people interested in doing things the hard way, and among those people the "old" paths to recognition and respect still operate, it just gets harder because there has to be a lot of trust between them that no one's taken the easy way out (AI) and pretended otherwise.
The C64 scene is still surprisingly active, and they usually do the seemingly impossible on such a limited hardware, while remaining incredibly creative (in how many ways could you phase out the C64 BASIC screen and show your demo't title?...). After the PC golden era I've been interested in the C64 only for a very, very long time, and I have not regretted it.
You just don't understand, it's the prompt and knowing which foreign work to endless rehash that's the new creativity now. There's taste in knowing what artist to steal from!
/s if that wasn't obv.
Who's going to show up to the next big demo party (like the ones they arrange in Europe), having e.g. hand coded 68k assembly or done some highly impressive 4k demo, having been intimate with every single instruction?
Revision attends approximately 1000 people.
Uh, many people. There are plenty of demo parties with retro categories in the compos, and plenty of people still interested in writing their own code for those platforms.
1 reply →
> the joy and creativity of writing code, of solving seemingly-impossible puzzles with ones mind
Find tougher puzzles then
That is a nonserious nonresponse.
Maybe it will just pass? Eventually maybe people will get bored of this consumerist mode of creation, of projects born with no vision or craft, made with the tastefulness of a kid smashing together their favorite toys. And when the majority finally agrees these stunts are a corrosive influence on the community, we can just approach it as a moderation problem, figure out some system of vouches and reports, or downsize and our communities until trust again becomes tractable, maybe even coming to appreciate some tactical slop as a stepping stone or a proof of concept to be eventually reverse-engineered into a maintainable human project.
It's the eternal sloptember, but for humanity.
Or an eternal heaven, our every wish coming true. The next iteration of homo sapiens will not be thinking how to do things, but what things to do. Is this the new creative space for us?
2 replies →
What makes you say this? Just because someone used AI to port some classic productions to the browser (which is actually pretty cool), doesn't mean that AI has taken over.
AI slop productions tend to be frowned upon, or even banned, writing code and using cool tricks to to what seems impossible is still a big part of the demoscene, in particular in the sizecoding, oldschool and wild categories. Clever use of AI is a debated topic, the demoscene is about pushing the limits of current technology, and AI is part of current technology. There is also the question of using AI for tooling (modelers, compressors, test harnesses, etc...), as in, will you stop using a particular IDE because it is written with the help of AI, even if it is good?
But still, most productions are hand made.
If there’s no human effort behind this, what’s the point? You could just as well watch any of the zillions of video recordings of these demos. There’s no inherent value in "running natively in the browser". Never mind the vast irony in demoscene specifically being a celebration of human skill and creativity.
Not going to say anything about AI translations. But the video recording don't do justice for many of demos.
The effects in some of the demos simply kill any video encoder, only way to properly experience them is by running or emulating locally. Not that crystal sharp upscaled square pixels on modern display or poor quality CRT filters are very representative either, but it's likely better than blurry mess you get when video encoder tries to deal with high frequency details or random noise from procedural effects.
I’m sure there are lossless recordings around. At 320x200x8bit even a simple sequence of PNGs wouldn’t take that much space in today’s terms.
2 replies →
I must have watched Second Reality almost a hundred times when I was younger. A video does not do it justice. This is the closest you can get on modern hardware.
Well, there is a little advantage. Most recordings are not at the native framerate, and have compression artefacts (which impacts some effects more than others)
Lack of CRT flicker is the biggest problem. Demo text scrolls are far more readable when you don't have sample-and-hold blur. There are gaming monitors with strobed backlights but I don't know of any that allow you to enable the strobing at 70Hz.
A workaround for modern hardware is frame doubling then blanking every other frame (software black frame insertion). It halves the brightness, but modern monitors generally support higher brightness than CRTs so this just brings it back to the authentic level. It's possible with FFMPEG filters, although I don't remember how I accomplished it when I tried it years ago.
The importance of CRT flicker is one reason I greatly prefer DOS demos to C64 and Amiga demos. Those were mostly designed for 50Hz PAL CRTs, so the flicker is far more annoying than 70Hz VGA.
I mean even these browser ports aren't at the native framerate. The native framerate for these demos was 70hz as they were all designed for VGA video modes.
7 replies →
It's quiet amazing how much people did with 4kb, 64kb demos.
even with 256 bytes: https://dosasm.com
bufff.... the music from second reality still gives me goosebumps.
How to skin a cat...
[dead]
[flagged]
I'm all for this future. Let's remove the tooling and let true creativity and diligence be what we appreciate and marvel at. If we can instruct AI well enough, it can eliminate the plumbing layer entirely, allowing us to focus on what truly matters.
Those demos from the '90s remind me of the incredible creativity and ingenuity of the human mind. Thanks for bringing them back to life and making them so effortlessly accessible.
Hilarious.
Haha.
2 replies →
>Those demos from the '90s remind me of the incredible creativity and ingenuity of the human mind. Thanks for bringing them back to life and making them so effortlessly accessible.
You don't need any AI for that. Just visit https://pouet.net
The demo scene is still very much happening.
You're welcome! These demos blew my mind in the early 90s and they still do today. Glad you enjoyed them!