Post

I'm experimenting with a way to show how DOS games render themselves. Basically I'm recording a lossless video of the game running on a very slow (virtual) CPU, then removing all the frames where nothing happens, and I'm playing it back sped up a lot.

283 reposts1.9K likes

it would be even cooler if you included another screen that's the whole addressable space and you show read/write as different colors. we could see where sprites are being read from etc.

I once created the graphics for a game that had multiple little people running around on the screen simultaneously, but we had to code it for a single bitmapped screen memory (Apple ][). A normal "save" and "restore" under each person would've left bits of other people behind if they overlapped.

I solved this by saving the background under each person in its restore buffer, drawing the person, then XORing its restore buffer. That way, "erasing" the drawn person wouldn't just blindly save/overwrite onto the background, it would XOR the drawn person away, and overlaps cleaned themselves up.

I remember there was a whole account dedicated to creating and posting these regularly, but I can't seem to find it here or on mastodon. Unless I misremember and I only followed it on Twitter.

1) I've been reverse-engineering TIE Fighter (1995), and I did a similar thing by placing a breakpoint at the start of the function that draws part of a rendered scene to VRAM, then taking snapshots of VRAM and compiling it into a gif. Discovered that the game uses a form of scanline rendering.

3) I manually blanked VRAM before doing this experiment, then remapped color 0 to dark purple to highlight that the render engine does not allow horizontal gaps between geometry in the scene, and will fill them in with the background color of space.

Reminds me of those text adventures with graphics e.g. The Hobbit on the ZX Spectrum - they would draw the graphics in a similar fashion (draw lines then add the colors via flood fills).

the GUI system they're using (I'm just calling it the broderbund UI in my reverse engineering work) DOES support avoiding this mess: you can tell it to hide the cursor, then when each sub-command tries to hide/restore it, it stays hidden, but they're not using it here.

i love that they redraw the mouse cursor multiple times probably unnecessarily. and they paint mouse cursor mask first, and then paint the cursor over it too, instead of doing a single pass. very insightful.

That's brilliant! It really showcases how the games render, i wonder if the sorting order was taken in mind by developers or if it's just simple system limitations.

reminds me a bit of my old VTech Socrates, which would play out elaborate animations of each background being drawn using line and fill tools you could skip them, which makes me wonder whether the animations were for show and it could do those operations instantly, or if they were cached in the ROM

A similar thing I did out of curiosity many years ago was hack DOSBox to dump EGA video memory on every frame, so I could see how various games implemented scrolling. Commander Keen 1 was famous for pioneering EGA scrolling, but CK4 refined it quite a bit.