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 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.

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.

Speaking as a 4k demo coder in the 2000s era, I think you're over generalizing. Decompression sure, but after that all bets are off.

What matters is how it performs on the party machine

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.

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

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?

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.

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!

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.

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

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.

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.