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…

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.

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 also made an interactive Dune globe renderer (in WASM and Rust!): https://thomas.fach-pedersen.net/dune/globe/

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.

Do "common men" not understand sensible examples or do you not have sensible examples?

https://nyheder.tv2.dk/business/2023-06-16-tdc-genkender-del...

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

What’s the one idiomatic idiom in C for a growable list of items? Because I must have a seen a hundred of those in my time.

What’s the one idiomatic idiom in C for a hashmap? I’ve seen about a hundred of those too.

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 :)

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 :)

So VanJS will make the simple things easy and anything else nigh-on impossible?

The Wire is very good.

It also features Idris Elba, so it has two British people playing Americans on either side of the law .