I've been slowly reverse engineering Cryo's Dune, coded by Rémi Herbulot in assembler, and the code is both brilliant and insane.
Every function (to the extent that you can call it a function in assembler) is manually tail call optimized, often to the point of just doing fallthrough by placing functions after each other.
All arguments and return values are passed in registers and flags. Sometimes I'm investigating where a pointer in the SI or DI register came from and I'll have to trace back through several function layers that just didn't touch those registers to find the place it was set. When you're looking at a function, all registers and flags are potential return values.
Everything is hardcoded, all the resource id's are fixed, extracting things from the resources files requires that you know what's where. In the file ATTACK, entries 0–52 are sprites, 53-55 are palettes, and he does math on the id's to find the previous/next one (dec/inc).
Some of the resource files are compressed, which you can tell by checksumming the 6 byte header. If the header bytes add to 0xAB and the third byte is zero, it's compressed.
In the video decoder, there are chunks for sound that start with SD, chunks for palette updates that start with PL, and chunks for frame data which are identified by them /not/ having a chunk identifer. That saves a whole 2 bytes per frame!
The globe renderer is a work of art, the room renderer constructs the game backgrounds from sprites, lines and polygons with randomly dithered coloring – although his implementation of the Bresenham line algorithm is slightly broken :). In the CD version the game has lipsync data embedded in the audio files.
I built in 8086 emulator just to help me reverse engineer this game…
> Fortunately `f64::parse` accepts a strict superset of JSON number grammar
Just for the sake of completeness, and not to imply that you don't know this, but the JSON spec doesn't limit the size or precision of numbers, although it allows implementations set other limits.
I have encountered JSON documents that (annoyingly) required the use of a parser with bigint-support.
On the other hand, about a decade ago I sent them a feature patch to support multipage tiff images and they sent me a Christmas card for a couple of years, so my impression of them is pretty god.
I've stopped going to Ars Technica exactly because their cookie pop-up lets me know that Condé Nast wants to share my data with at least (according to the popup) 159 partners.
They have so many "partners" that their cookie popup comes with a search bar.
56 of their "partners" want my precise geolocation data!
16 "partners" want to actively scan my device!
101 "partners" want to "match and combine data from other data sources" (I can't disable or object to this)
102 "partners" want to identify my device. I also can't object to this.
The only way I can really object is to close the tab, so that's what I do.
I've been entertaining myself lately by reverse engineering Cryo's Dune. I've got all graphics resources (videos, sprites, rooms) decoded, and I have recreated most of the intro (which exercises a good deal of engine).
It should be pixel accurate to the in-game one, although I haven't validated it lately.
It's very slow going though. The original game was coded in highly optimized idiosyncratic 8086 assembly. It's difficult to read, much more so than compiler-generated machine code from the same era.
Of course I'm talking about an idiomatic implementation, what else would I be talking about in this context?
> The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it.
That sounds like a long-winded way to say "there's no one idiomatic growable list in C".
There are no original compilers of SCUMM script available online as far as I know, although certainly Ron Gilbert and Aaron Giles and probably some other LucasArts programmers have the originals.
I don't think there were even any samples of the original scripts online when ScummC was developed so it can be forgiven for not matching the original format :)
You can study the reverse engineered code of a lot game engines. ScummVM is a massive collection of reverse engineered game engines, with the occasional donation of original game code from kind developers.
ScummVM is not emulation, it's primarily a collection of reimplementations of game engines based on reverse engineering, with the occasional donation of original source code from the developers.
So with ScummVM you can study how the original SCUMM virtual machine worked, but to see the original SCUMM scripts before they were compiled we have to rely on the kindness of Ron Gilbert :)
Here's the AdLib/SoundBlaster Pro version of the track Morning played by a reverse engineered driver, rendered by nukeykt's Nuked-OPL3.
https://www.youtube.com/watch?v=n0l_CYH4njw