madmoose
Joined 17 years ago
Joined 17 years ago
Any look in older games, 2d or 3d, can be achieved on modern GPUs, so that seems like a vacuous thing to state.
It's firmly lodged in my fingers still.
Here's the AdLib/SoundBlaster Pro version of the track Morning played by a reverse engineered driver, rendered by nukeykt's Nuked-OPL3.
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://mastodon.social/@madmoose