Read on Twitter
I don't use Twitter very often, but for a few days now I've wanted to share my "quarantine project" 
This project is about an old MSDOS game I love: Supaplex.
This project is about an old MSDOS game I love: Supaplex.
Last year I ported another old game to Nintendo Switch: Triplane Turmoil ( https://github.com/sergiou87/triplane-turmoil). Luckily there was already a port to SDL 1.2. It just needed an upgrade to SDL 2 and a few fixes! It was fun, so I wanted to port other games from my childhood
However, I couldn't find the source code of any of them. I tried reaching the original authors of those games, but no luck, so I gave up and went back to other hobbies. Then, this year, with COVID-19 around the corner in Spain, I got the "itch" again for porting an old game…
I found an interesting project about Supaplex: https://github.com/cilliemalan/supaplex
It was "an effort to disassemble and understand the speed fix code once again". It already had a few symbols renamed, a few comments. Enough to get me started, but still feel like a challenge.
It was "an effort to disassemble and understand the speed fix code once again". It already had a few symbols renamed, a few comments. Enough to get me started, but still feel like a challenge.
My goal was different: I wanted the C code of the game, reimplement all the input/graphics/audio code in SDL and make it open source and available for any platform we want. All that using the original game data files.
So at the beginning of March I just started working on it!
So at the beginning of March I just started working on it!
The first 2 weeks were just about translating asm code blindly to C in Sublime Text. I couldn't run or build that code, of course. My intention was to get enough translated until I got something "useful" I could see on the screen, when I could see my first bitmap.
When I was close to that, I just created an Xcode project and linked SDL to be ready for it.
I got a bit stuck because VGA code in x86 asm is painful, so I tried to reverse-engineer the bitmap format of the game data files instead and assume that just drawing that bitmap on the screen is enough 
In a first naive approach to decode those bitmaps, I found that they had the original image in 4 columns. Later I understood how to combine them to get the image I was looking for.
Yes, the colors were wrong. I hadn't sorted out color palettes yet
Yes, the colors were wrong. I hadn't sorted out color palettes yet
A bit more of work and finally I got my first bitmap on the screen!
Then I got palette transitions for fade in/out and other nice effects and finalized the "intro sequence".
After that I started working on the main menu. With that I would need to reverse-engineer mouse/keyboard input, many file formats, more graphics code… Took me around a week to have it all working!
The next step was the actual game. In the end it's an engine that you feed with levels, and it Just Works™. I started reverse-engineering the level file format and how to draw it on the screen… but everything was static.
It took me 2 weeks of more blind work to get something moving around. Two whole weeks translating procedures of 1,000-2,000 lines of asm code to C without being able to run or build that code. Painful. But… I was able to move Murphy around! Finally!
Then I fixed the animations, reimplemented some basic interaction with the environment…
Then reimplemented bomb and infotrons physics, explosions…
And with another week of work I finished reimplementing all physics and AIs of the game (mostly, at least), fixed many bugs and I was able to finish a level!
During all this process I used the awesome DOSBox debugger to either understand what the original code does or to make sure my reimplementation does the same when I found a bug. Breakpoints, step over/into, examine any part of the code/data… super powerful!! 
Other times I would just make small changes in the original asm code (mainly commenting out procedure calls) from cilliemalan's repo, rebuild it with TASM, and see the effects my changes had. That helped me understand the purpose of parts of the code.
Finally, I was in a position to do what I was looking for. And that's how I finally ported it to PS Vita…
…and Nintendo Switch! 
Builds for both platforms are generated automagically thanks to a couple of GitHub Actions (
).
Builds for both platforms are generated automagically thanks to a couple of GitHub Actions ().
All this work is open source and available at https://github.com/sergiou87/open-supaplex
If you like it, please
my repo!
If you like it, please
my repo!
Next steps: finish reimplementing the rest of the game specially getting the music and sound effects working. That's gonna be fun!
specially getting the music and sound effects working. That's gonna be fun!
