Every Friday, this repurposed little piece of networking gear in my living room builds the latest version of Chocolate Doom from Git, and automatically plays through over 600 hours of demo recordings to ensure that demo sync works as intended.
The machine is an Edgerouter Lite 3 running OpenBSD and I specifically chose it because it has a big-endian MIPS CPU. So not only is it testing that the demos play back correctly, it's testing that they'll play back correctly even if you want to use weird hardware and an uncommon operating system.
And by the way - Friday it does Chocolate Doom, but Tuesdays it does Crispy Doom. Running through all those demos takes about 12 hours; this is not exactly what the hardware was designed for.
It's kind of funny to think - this machine has no screen, nor does it have any way you easily *could* connect a screen to it, but nonetheless - it runs Doom. Silently, visibly, internally, it is playing Doom, at around 50x the normal speed.
@fraggle like a prayer wheel
@fraggle Extremely cool. How do you determine that each demo has played back 100% correctly? Is this code that's in Chocolate Doom's source depot?
@jplebreton DOS Doom has an obscure option called '-statcopy' that lets an external driver get access to the intermission screen statistics data. So I wrote a DOS driver that dumps this to a text file, and ran it across the entire Compet-N archive. Choco can generate the same text files, and as long as the demo stays in sync, the two will match. http://github.com/chocolate-doom/statcheck
@fraggle Brilliant! Clever use of that feature.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!