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
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.
Even with a cycle accurate CPU you'd still have a lot of variation caused by the motherboard chipsets, DRAM speeds, cache chips and graphics cards.
Tseng ET4000 was on a completely different level than something like Cirrus Logic CL-GD510 or heaven forbid, Oak Technologies card.
If the era appropriate PCs had huge variations, what extra does cycle accuracy really bring at this point? The same PC demo could perform very differently on two 486DX2 66 MHz PCs.
Wrt CPU: The cycles per instruction measures were entirely predictable with 386 and 486 chips, and more-or-less so with early Pentiums, you just need a delay loop so the faster ones didn't speed ahead of the lowest you were targetting. While there was a significant range to deal with, it was predictable. A 4K demo is going to fix in a 486's on-board cache (which I don't think was ever less than 8Kb aside from some relatively rare clone models), so DRAM speed, L2 cache and other motherboard variances, are not significant in those cases either.
Wrt GFX: Most demos, certainly when thinking about the 4K challenges, would be using nothing more than some variant of a basic VGA display mode (usually but not always Mode 13h or some variant like “Mode X”) without detecting and taking advantage of acceleration features - the difference between graphics cards at this point was not nearly as significant as what the demos were doing in the CPU, even the nastiest ISA card of the era is going to keep up at a reasonable framerate, IIRC from my doom playing days.
The first thing a 4k demo is going to do is to decompress executable. The second thing is to procedurally generate assets. Perhaps also do some code generation. So the cache footprint is going to be larger.
At this point you can be talking about 600 kB on a DOS machine. Sky is the limit on modern systems.
That said, typical inner loops of that era demos were pretty small, usually 20-200 byte range, IIRC.
Pre-cache era demos often had huge unrolled self-modifying speedcode inner loops, but that's another matter.
> 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.
> 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?
But having learned from the feedback they or you then go off to work on something else and, unless you move onwards/upwards/both in perfect sync, and you end up with new juniors who need the feedback afresh.
Also: I've always avoided being anything like a lead or manager, but I do effectively have a couple of relative juniors ATM who I wish would have a better long-term learn/forget ratio when it comes to feedback from myself and elsewhere!
Okay yes "fight so hard" might have been a bit stronger sorry for that. But it was more in line with "this has become so annoying recently" rightly so because yes you do need to remove the cruft that has nothing to be here and I don't remember being such as issue 6 months ago. The other part of it is to regularly remind colleagues of this rising issue because as I said, even experienced people tend not to care anymore, and this is saddening me.
And while in 2025 I considered AI coding agent in the realm of junior devs, we have been way way past that since early 2026 honestly.
> 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.
Ah yeah true, no I don't think you're misunderstanding. Actually sorry I misspoke - what I've seen in the game re/decomp projects is that the binary gets turned into a direct C implementation of the instruction stream, and it's basically a sort of emulation with CPU/memory state and emulation of whatever hardware it might need to talk to.
I agree on this description. It looks like a wrapper for an app alias demo, not a generalization for all app following the hardware possibilities at the time.
On the other hand, at least these folks build and create and I prefer wrapper demos instead of a perfect emulator that will never finish.
Nevertheless, on the feature side of these wrappers I really miss a fast-forward option. If you go pseudo-emulation, then at least come up with some convenience features.
Maybe this is the irony: the ff button is perfectly legit, I used mine many times with the 486DX3-100 and Pentium 133. Back then it was called turbo button.
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
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.
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.
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.
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.
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?
But the thinking is the valuable and meaningful part. I don't want it monopolized by a few megacorps, sterilized and devoid of human touch, only thinking of things that said corps find acceptable.
We'll get unlimited frozen pizzas, but we'll kill off chefs in the process.
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.
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.
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.
Glad to hear that! But then again, might be hard to know how their approach was. Traditionally people write a lot of code and prepare before the compos, it didn't all come during those few hours.
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?
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.
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!
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.
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.
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.
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)
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.
My monitor's standard and actual rate is 165 Hz, which is probably not terrible at approximating 70 Hz (very few fps from a small multiple of 70 would be worst).
High fps is probably a little more rare than HiDPI, but also becoming more common. It's already common in phones.
Sure. I don't think I've ever had an LCD monitor that supports 70hz at a useful resolution though. My current monitors (native resolution 2560x1440) only seem to support it at 1024x768!
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.
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.
Just did a quick test 320x200x8bit grayscale PNG (couldn't quickly figure out how to get 8bit color pallet) compressed to ~15-40kB. Multiply that by 60frames a second (or whatever odd framerate historic hardware used) and 120seconds and you get 200MB. Not completely impractical, but I wouldn't call it trivial amount of space. And if you find any demoscene collection providing losslessly compressed videos let me know. All I have seen is original executable+youtube video (which suffers from compression artifacts). And I doubt many demoscene website maintainers are eager to increase their storage and bandwidth costs 100x.
Fair, it’s indeed a shame if there aren’t lossless or very-high-bitrate lossy recordings available. A literal sequence of PNGs is of course an upper limit, using temporal coherence (of which there’s a lot of) would shrink the size to maybe a few tens of megabytes. But of course there aren’t many lossless video formats in common use because it’s a rather niche use case outside mastering and archival. There’s lossless H.264 and H.265, and IETF’s FFV seems pretty well-supported too. Not sure if browsers support them though.
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.
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.
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 :)
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.
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.
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.
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.
How far do you want to go? Obviously many demos were not written using ones and zeros and most likely the coders used compilers and assemblers to produce the binaries. They were also using linkers instead of merging the files by hand. Many learned the stuff using books, so it is just regurgitation of what they read in those books.
As with AI it's no different than delegating work to a group member. What counts is vision and execution.
Not sure. Corporations do it all the time. They create vision, hire employees to make it real and then it is the company's vision and execution. The demos are typically released under demoscene group name, not individuals who contributed.
I think many people are confused what's AI has given to them. An ability to be a boss. Something that used to be afforded to the rich. Now you can assemble a "team" and deliver whatever idea you have in mind without spending thousands or millions.
What a weird argument, I can't believe people say that sort of thing and mean it sincerely. Compilers and assemblers and linkers and books are not the same as using AI. They're not just both tools and equivalent. One is using your brain power to gain knowledge and learn how things work. The other is asking someone to make the thing for you. But I don't think we'll agree on anything here.
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.
The demoparty Assembly actually has an vibe coded demo competition.
And maybe that is a solution to the problem, but it just does not interest me.
Sceners are no strangers to imposing artificial constraints on themselves. Just look at high end 64k, 8k, 4k, and 256byte intro coding, there is no real reason for it other than the challenge. So I really hope this mindset can be applied to AI use as well.
I think the point is your not outputting anything. For crud apps that's fine but an activity where the whole point of it is to show off your technical skills it seems quite pointless.
That's a bit nonsense though isn't it? The bot isn't showing up to the party and coming up with a plan to present. The person is operating the machine, and without the person there's no output.
If I can beat someone's technical skills with AI what are their technical skills worth? That's the question that a lot of people are struggling with right now.
If you can come up with a problem that a human can solve better without AI, then that's an interesting competition and the tools involved wouldn't end up mattering much.
Now if the contest is "who can develop the best/smallest/fastest app without AI" that's completely fine, there are similarly "who can cut the most grass with a scythe" competitions and everyone involved knows what they're signing up for and has a good time. Nothing wrong with that.
> The person is operating the machine, and without the person there's no output.
> If I can beat someone's technical skills with AI what are their technical skills worth? That's the question that a lot of people are struggling with right now.
I could turn up on a chess competition with a chess machine and beat my opponents with it, but that is not the point of chess competitions
Well of course, they have rules preventing it. No one's saying "you can't have rules that ban AI from demoscene" or "Demoscene must use AI." There are also exhibitions where chess pros compete against machines.
This isn't about a chess pro competing against a machine, this is about someone showing up and saying they're going to enter the competition but instead they run a chess program, and claim that they played against the chess pro and beat them.
> if everyone is using AI, wouldn't the bar also be raised for everyone
Why would I care about vibe coded a demo when I could just ask Claude to make the same thing for me?
If you have two demos side by side, one AI and the other human, the human version is immediately more interesting because it showcases a high level of skill that you may aspire to achieve one day. The AI version is as forgettable as the person who prompted it, because it does not demonstrate that person's skill.
Same reason why we generally find weightlifters to be impressive even though machines have been able to out-lift anyone for thousands of years.
That said, I don't think most people dislike using it for tedious work or information searching. Similar to how most are still impressed by a lifter using a Smith machine to stabilize an absurd weight.
Why would you care about any code product when you could ask Claude to make the same thing for you? Again, this is a question many are struggling with right now.
There will always be competitions that limit tool use, and competitions that don't. There are many examples that go either way.
The demoscene is all about showing off technical skill.
Using AI requires next to zero technical skill.
That's the key.
I think the problem is that you think of demoscene as just fancy videos, but it's actually about making a fancy video while dealing with serious constraints. In the classic demoscene of the 80s/90s, that constraint was processing power or RAM. In the modern day, processing power is immense, so people make the constraints artificial, such as putting a limit on your executable size.
Using AI to produce a demo within constraints is simply not impressive.
AI isn't a tool the way a debugger, compiler, or IDE are. It's more like outsourcing your work to someone else, then taking the credit for producing it.
It's about how much control over the tool and the output the artist has. A photocopy machine and a pencil are both tools that can be used to make a copy of a photo. The machine is much faster than the pencil and produce a very accurate result, but only the pencil version has artistic value. The resulting artifact artistic value is a token that represents the creation process.
One is building a thing using your own knowledge and creativity and the other is building a thing utilizing the largest collection of stolen knowledge and stolen creativity
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.
There is no shortage of crap demos that were not "vibe" coded.
I am just saying that AI is also something to harness, show it can help create something mindblowing. I am not saying that everyone should now go and type: "Make me a blob animation with phong reflections, put a bouncy scroll bar with 80s looking fonts and craft Ikari style chip tune and book tickets to the next demoscene party".
You can show raw skill with AI used as a tool. Demoscene is not a suffering contest otherwise you might start questioning why the demos in the past were not written using ones and zeros, but they used assembler that makes it soooo easy!
Because there is no natural right for you to be part of a scene. The right is earned, and every scene does well by keeping posers and mouthbreathers out.
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.
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
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.
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.
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!
Retr0id | 13 hours ago
> 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.
vardump | 13 hours ago
dspillett | 12 hours ago
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.
vardump | 10 hours ago
Even with a cycle accurate CPU you'd still have a lot of variation caused by the motherboard chipsets, DRAM speeds, cache chips and graphics cards.
Tseng ET4000 was on a completely different level than something like Cirrus Logic CL-GD510 or heaven forbid, Oak Technologies card.
If the era appropriate PCs had huge variations, what extra does cycle accuracy really bring at this point? The same PC demo could perform very differently on two 486DX2 66 MHz PCs.
dspillett | 7 hours ago
Wrt GFX: Most demos, certainly when thinking about the 4K challenges, would be using nothing more than some variant of a basic VGA display mode (usually but not always Mode 13h or some variant like “Mode X”) without detecting and taking advantage of acceleration features - the difference between graphics cards at this point was not nearly as significant as what the demos were doing in the CPU, even the nastiest ISA card of the era is going to keep up at a reasonable framerate, IIRC from my doom playing days.
vardump | 6 hours ago
At this point you can be talking about 600 kB on a DOS machine. Sky is the limit on modern systems.
That said, typical inner loops of that era demos were pretty small, usually 20-200 byte range, IIRC.
Pre-cache era demos often had huge unrolled self-modifying speedcode inner loops, but that's another matter.
EvanAnderson | 8 hours ago
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.
rmnclmnt | 13 hours ago
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
christophilus | 13 hours ago
rmnclmnt | 13 hours ago
dspillett | 13 hours ago
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?
Sharlin | 12 hours ago
dspillett | 12 hours ago
Also: I've always avoided being anything like a lead or manager, but I do effectively have a couple of relative juniors ATM who I wish would have a better long-term learn/forget ratio when it comes to feedback from myself and elsewhere!
Retr0id | 12 hours ago
rmnclmnt | 10 hours ago
rmnclmnt | 10 hours ago
And while in 2025 I considered AI coding agent in the realm of junior devs, we have been way way past that since early 2026 honestly.
bananaboy | 12 hours ago
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.
Retr0id | 12 hours ago
bananaboy | 11 hours ago
_the_inflator | 11 hours ago
On the other hand, at least these folks build and create and I prefer wrapper demos instead of a perfect emulator that will never finish.
Nevertheless, on the feature side of these wrappers I really miss a fast-forward option. If you go pseudo-emulation, then at least come up with some convenience features.
Maybe this is the irony: the ff button is perfectly legit, I used mine many times with the 486DX3-100 and Pentium 133. Back then it was called turbo button.
pjc50 | 11 hours ago
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.
whizzter | 10 hours ago
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
gritzko | 13 hours ago
cyclopeanutopia | 13 hours ago
gritzko | 13 hours ago
timdiggerm | 8 hours ago
dspillett | 13 hours ago
bananaboy | 12 hours ago
1313ed01 | 13 hours ago
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.
gritzko | 13 hours ago
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.
chriswarbo | 12 hours ago
IIRC Windows 9x & ME were based on (MS)DOS; but 2k and XP were based on NT, which was quite different.
(Note sure what those differences actually are, since I only started programming once I'd switched to Linux...)
bananaboy | 12 hours ago
gritzko | 11 hours ago
vrganj | 13 hours ago
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.
plastic-enjoyer | 13 hours ago
blackhaz | 13 hours ago
vrganj | 13 hours ago
We'll get unlimited frozen pizzas, but we'll kill off chefs in the process.
It's not a trade I'm feeling good about.
iberator | 9 hours ago
godshatter | 7 hours ago
Have you ever soured on a video game because you downloaded a "god mode" cheat?
mrweasel | 13 hours ago
It's really cool to be able to rewatch these demo, but the spirit in which they were created is somewhat lost.
KellyCriterion | 12 hours ago
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! :-)
smokel | 12 hours ago
But it did require a 386, which typically had 2 MB or more of RAM back then.
bananaboy | 12 hours ago
leptons | 11 hours ago
https://www.pouet.net/prod.php?which=1216
bananaboy | 10 hours ago
pona-a | 13 hours ago
sgt | 13 hours ago
bananaboy | 12 hours ago
sgt | 12 hours ago
cowlevel | 9 hours ago
GuB-42 | 12 hours ago
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.
bananaboy | 12 hours ago
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.
akoboldfrying | 10 hours ago
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.
Krei-se | 12 hours ago
/s if that wasn't obv.
haspok | 10 hours ago
gritzko | 10 hours ago
Find tougher puzzles then
vrganj | 9 hours ago
Krisso | 13 hours ago
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.
Sharlin | 13 hours ago
Krisso | 13 hours ago
KellyCriterion | 12 hours ago
r_lee | 11 hours ago
treylorswift | 13 hours ago
leptons | 11 hours ago
You don't need any AI for that. Just visit https://pouet.net
The demo scene is still very much happening.
Sharlin | 13 hours ago
Retr0id | 13 hours ago
bananaboy | 12 hours ago
Retr0id | 12 hours ago
Sharlin | 11 hours ago
ahartmetz | 10 hours ago
High fps is probably a little more rare than HiDPI, but also becoming more common. It's already common in phones.
bananaboy | 11 hours ago
Retr0id | 11 hours ago
bananaboy | 10 hours ago
mrob | 10 hours ago
mrob | 10 hours ago
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.
Karliss | 12 hours ago
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.
Sharlin | 12 hours ago
Karliss | 11 hours ago
Sharlin | 10 hours ago
inoop | 9 hours ago
Martin_Silenus | 12 hours ago
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.
smokel | 12 hours ago
But watching Crystal Dreams II on my phone actually made me feel young again :)
Martin_Silenus | 12 hours ago
haspok | 11 hours ago
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.
cowlevel | 10 hours ago
whizzter | 10 hours ago
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.
melicerte | 12 hours ago
joking | 12 hours ago
meerita | 12 hours ago
novaRom | 12 hours ago
futurecat | 11 hours ago
State of the Art was ported to the browser as well.
velo_aprx | 10 hours ago
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.
freecodeio | 10 hours ago
doubled112 | 10 hours ago
ashleyn | 10 hours ago
shermantanktop | 7 hours ago
varispeed | 10 hours ago
Demoscene should embrace it.
teddyh | 9 hours ago
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.
varispeed | 6 hours ago
As with AI it's no different than delegating work to a group member. What counts is vision and execution.
teddyh | 3 hours ago
If I delegate something to somebody else, I can’t then claim that I made it, because of my “vision and execution”.
varispeed | 3 hours ago
I think many people are confused what's AI has given to them. An ability to be a boss. Something that used to be afforded to the rich. Now you can assemble a "team" and deliver whatever idea you have in mind without spending thousands or millions.
teddyh | 17 minutes ago
And most people have personal experience with how much a boss actually contributes.
bananaboy | 44 minutes ago
velo_aprx | 9 hours 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.
micromacrofoot | 9 hours ago
velo_aprx | 8 hours ago
micromacrofoot | 8 hours ago
I suppose it would be interesting to have a random split, half use AI half don't, judging is blind and see what the outcome is
velo_aprx | 7 hours ago
Sceners are no strangers to imposing artificial constraints on themselves. Just look at high end 64k, 8k, 4k, and 256byte intro coding, there is no real reason for it other than the challenge. So I really hope this mindset can be applied to AI use as well.
venzaspa | 7 hours ago
I think the point is your not outputting anything. For crud apps that's fine but an activity where the whole point of it is to show off your technical skills it seems quite pointless.
micromacrofoot | 7 hours ago
If I can beat someone's technical skills with AI what are their technical skills worth? That's the question that a lot of people are struggling with right now.
If you can come up with a problem that a human can solve better without AI, then that's an interesting competition and the tools involved wouldn't end up mattering much.
Now if the contest is "who can develop the best/smallest/fastest app without AI" that's completely fine, there are similarly "who can cut the most grass with a scythe" competitions and everyone involved knows what they're signing up for and has a good time. Nothing wrong with that.
plastic-enjoyer | 7 hours ago
> If I can beat someone's technical skills with AI what are their technical skills worth? That's the question that a lot of people are struggling with right now.
I could turn up on a chess competition with a chess machine and beat my opponents with it, but that is not the point of chess competitions
micromacrofoot | 6 hours ago
bananaboy | 49 minutes ago
StableAlkyne | 7 hours ago
Why would I care about vibe coded a demo when I could just ask Claude to make the same thing for me?
If you have two demos side by side, one AI and the other human, the human version is immediately more interesting because it showcases a high level of skill that you may aspire to achieve one day. The AI version is as forgettable as the person who prompted it, because it does not demonstrate that person's skill.
Same reason why we generally find weightlifters to be impressive even though machines have been able to out-lift anyone for thousands of years.
That said, I don't think most people dislike using it for tedious work or information searching. Similar to how most are still impressed by a lifter using a Smith machine to stabilize an absurd weight.
micromacrofoot | 6 hours ago
There will always be competitions that limit tool use, and competitions that don't. There are many examples that go either way.
Sohcahtoa82 | 6 hours ago
Using AI requires next to zero technical skill.
That's the key.
I think the problem is that you think of demoscene as just fancy videos, but it's actually about making a fancy video while dealing with serious constraints. In the classic demoscene of the 80s/90s, that constraint was processing power or RAM. In the modern day, processing power is immense, so people make the constraints artificial, such as putting a limit on your executable size.
Using AI to produce a demo within constraints is simply not impressive.
AI isn't a tool the way a debugger, compiler, or IDE are. It's more like outsourcing your work to someone else, then taking the credit for producing it.
petterroea | 8 hours ago
flpm | 7 hours ago
culi | 7 hours ago
petterroea | 8 hours ago
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.
varispeed | 5 hours ago
I am just saying that AI is also something to harness, show it can help create something mindblowing. I am not saying that everyone should now go and type: "Make me a blob animation with phong reflections, put a bouncy scroll bar with 80s looking fonts and craft Ikari style chip tune and book tickets to the next demoscene party".
viccis | 7 hours ago
Opinion ignored.
Sophira | 7 hours ago
This obviously intersected broadly with getting the most out of technology, but the main purpose was always (and still is) showing skillsets.
varispeed | 6 hours ago
plastic-enjoyer | 7 hours ago
Because there is no natural right for you to be part of a scene. The right is earned, and every scene does well by keeping posers and mouthbreathers out.
myth_drannon | 9 hours ago
cowlevel | 9 hours ago
velo_aprx | 8 hours ago
dr_win | 7 hours ago
velo_aprx | 7 hours ago
CursedSilicon | 7 hours ago
jasomill | an hour ago
It's equally essential, of course, to never misrepresent one as the other.
And "remasters", again just like video games, are very much a matter of taste (on the part of both creators and consumers).
momocowcow | 9 hours ago
gregkb | 9 hours ago
petterroea | 9 hours ago
sedan_baklazhan | 8 hours ago
And I didn't do any coding to achieve that. Cool right?
Eh.. no. A completely boring negation of what demos are about.
alphasm | 8 hours ago
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!
archagon | 17 minutes ago