Notices by Niko (lethal_guitar) (lethal_guitar@mastodon.social)

Been doing a fun new reverse engineering project: Figuring out the file formats of the 1999 Windows/PS1 game Attack of the Saucerman. It's the first time I'm doing this on a 3D game. I'm now at a point where I can partially display the levels, and extract most of the assets:
https://github.com/lethal-guitar/SaucerMapViewer

I already made an attempt many many years ago, but was only armed with a hex editor at the time and couldn't make any sense of the data. (cont.)

It even still calls the OutputDebugString API, so when you run the game with a debugger attached, you can see all these log messages!

Here's a selection of some funny messages:

"You madman! You're running a 24-bit desktop! It'll be slow.."
"Created Too Many Models! TALK TOO [sic] TIM NOW!!!"

I'll probably put this on pause for a little bit, but intend to continue at some point - I'd like to at least get 3D models displaying in the level viewer, and ideally figure out the lighting system.

This time, I started by disassembling the EXE using Ida, and was able to identify the overall structure of the files. Once I knew how the level files are laid out, I was then able to make targeted changes and observe the result when running the game, which helped fill in most of the gaps, alongside more disassembly. What also helped a ton was a good number of debug log strings left in the code by the devs. (cont.)

@foone for sure! I wonder if they did that on purpose to be able to implement effects like this, or if it was more of a happy accident.

Next blog post about DOS games graphical effects is out! We're looking at the underwater "filter" in Duke Nukem 2 this time:
https://lethalguitar.wordpress.com/2024/07/19/graphical-effects-in-duke-nukem-1-2-part-2/
Featuring more Assembly and EGA shenanigans 😎

New blog post! This time we're examining how the reflective floors in Duke Nukem 1 were implemented:
https://lethalguitar.wordpress.com/2024/07/13/graphical-effects-in-duke-nukem-1-2-part-1/

@foone Not 16-bit x86? ;)

@foone I feel like I actually remember you posting about some project that required an old Python build back on the birdsite. Don't recall what exactly it was though..

@foone interesting!!

@foone I guess when you're programming in Assembly it's more convenient to use registers instead of setting up variables in memory. But still feels wrong for the interrupt to not save/restore all registers.

@foone or is this just Ghidra misinterpreting the Assembly?

@foone these loops look weird - wouldn't the interrupt just return to the same place when done and the loop would keep running? How would these loops ever stop?

Our dissection of Duke Nukem 1's internals continues! Looking at collision detection this time:

https://lethalguitar.wordpress.com/2023/12/12/duke-nukem-1s-collision-detection/

More Duke Nukem 1 fun facts: The red bouncy mines don't actually bounce off the floor. There's no collision detection or physics there - they just move up and down by a fixed amount. If you place one higher up, it bounces in the air 😄

This is basically the entire movement logic:
https://gist.github.com/lethal-guitar/6ca0aa69786c7ad8a2319489503850b0

A fun little detail in Duke Nukem 1 I never noticed until reverse engineering the game: The blue boxes with balloons fall at half the speed of every other type of box. At first I thought it must be a mistake, but now I think it's intentional: Because the helium balloons inside the box make them float down more slowly!!! 🤯

Back in 2006, while still in highschool, I wrote a level editor for Duke Nukem 2. I've never shared it publicly before, as the code is pretty crappy and I have no plans of developing it any further. But maybe it'll be of use to someone, so I decided to release it:

https://github.com/lethal-guitar/Duke2Edit

I'm happy to answer questions if anyone is interested in picking this up and working more on it!

Source code for the original DOS version of Raptor: Call of the Shadows has been released:
https://github.com/skynettx/dosraptor