I've exchanged a couple of emails with the author a while ago. Reverse-engineering and decompiling DOS software running in real mode and especially video games is a particularly tricky endeavor, a notch above other similar projects on other platforms.
The combination of janky PC hardware, paper-thin MS-DOS operating system and prehistoric development tooling makes for an environment where anything goes. Real mode segmented memory and large memory models utterly confuse Ghidra's analyzers and decompiler, most common modern reverse-engineering tools either do not support 16-bit MS-DOS executables or have third-rate support.
It is more art than science in a way that I don't think reverse-engineering later software can match.
It's a little awful to think about just how much collective human effort was wasted by segmented memory. Everyone knew that 32-bit flat memory was the future; it just took a long time for the PC platform to get there.
Yeah, but when you are shipping computers with 256kb like the original PC/XT those extra two bytes per pointer start to look like a major luxury. There was a heroic amount of effort in those days to make due with as little memory as possible because memory was so expensive that nobody had more than was absolutely necessary.
IDA Pro disassembler fully supports 16Bit DOS executables (they only removed the support from the recent free versions - thats why most using IDA Pro Free 5.0) but Hexrays the decompiler does sadly not support 16bit code (intentionaly) but i think the Hexrays guys could do wonders here (in comparison what Ghidra is able to do)
My beloved was a little bit newer DOS game F22 Lightning II. The best memories I have from it are when I was cycling through targets, and there was Air Force One which we were escorting. And just because I had armed missiles, AWACS detected radio pulses on the Air Force One, and every other aircraft in the air shot a missile on my machine. This caused first of all my computer to lag, then "incoming missile" from the speaker repeated hundred times, and after that I saw an animation of all the other missiles flying through the remains of my plane. Wonderful experience
When I was about 8 years old I can remember walking into the office at home this game was on the screen. One of the fighters was flying towards an airstrip and I thought I'd helpfully land it, I crashed. Turns out dad had it on autopilot to return to home after some mission which he had to repeat thanks to me :)
I've thought to myself that if I want a cool project that would motivate me to re-learn C just for the sake of making an NES game (ala 8-bit workshop - https://8bitworkshop.com/), I would really like to learn how to apply the pseudo-3d or 2.5d methods that were used by Microprose in F-19 Stealth fighter.
I don't know the first thing about 3D programming. I tried to follow a book on writing a ray-tracer from scratch just to see if I could pick up the principles and do it myself, but I got frustrated by the ambiguity of the approach. Like I was trying to use Ruby with Rspec, but I'm not even sure if I'd run into a performance issue or not be implementing the interfaces correctly.
I just want to know what method was used. Maybe 3D projection?
Kind of like how Myst was able to deliver ultra-high resolution 3D images in a video game in ways that had never been done before, even though it was really just a point-and-click slideshow with embedded videos and scripted interactions (Hypercard)... Hellcat Ace provided an experience far ahead of its time.
> I would really like to learn how to apply the pseudo-3d or 2.5d methods that were used by Microprose in F-19 Stealth fighter.
F-15 is not pseudo-3d at all.
Flight simulators were early innovators in proper polygon based graphics. Partly because there were so few polygons they could get away with the painters algorithm. Partly because the instrument panel could cover a large chunk of the screen. But mostly because players of flight sims were willing to put up with very low frame rates, even 1 frame-per-second would be considered playable for certain types of flights.
Anyway, the tricks used for the 8 bit computers and consoles were nothing more than distilling down the graphical complexity until all they really had to draw was a tilting horizon line and then use a few sprites for everything else.
The one notable pseudo-3d technique I'll point out is the voxel based terrain used by "Comanche: Maximum Overkill". That's well documented.
On the NES (or other 6502 machines), use assembly. That CPU just isn't a good target for C - pointers are awkward, you can't really do stack frames, and the addressing modes don't even support 'structs' very well. Fun to program assembly on, though. For your purpose the NES makes it double hard because it hardly has any ram (2 KB, and typically an additional 8 KB inside each cartridge except in the oldest games), and a character-mode graphics architecture rather than a framebuffer. If you do really want to do an 8-bit flight sim, the Atari 400/800 machines are an okay target. The Atari ST would be a better target.
Speaking of those machines, I'd love to see someone deeply reverse engineer the pseudo-voxel/fractal landscape engine that Lucasfilm Games invented for Rescue on Fractalus, Koronis Rift, etc. It still seems completely magical that they could pull that off on a machine with those specs.
Starting from zero, you might start at a high level and work your way down. Do a simple polygon flight engine using OpenGL and your favorite high level language of choice. Then write your own polygon rasterizer that you can overlay versus the OpenGL rendering as a reference. Then maybe rework it in pseudo 8-bit code (C constrained to only unsigned char variables, or similar), which should translate directly to assembly language on the target of choice. On a real 8-bit machine, unless you want low single digit frame rates, you probably have to pull a lot of dirty tricks. Maybe a 16-bit platform would be a better choice. This is speculative - I learned 3D (to a novice degree..) on a 486 PC under 16-bit DOS using C and assembly for inner loops (bitblts, texture mapping).
There's something about the aesthetic of late 80s PC flight sims (F-19 Stealth Fighter, LHX Attack Chopper, etc.) and their flat shaded polygon graphics that feels in vogue right now. Check out Thunder Helix on Steam.
Anyway there's definitely a magical feeling writing graphics code when you get your first feeling of realistic movement and rotation in 3D space working. Hopefully the ubiquity of ultra-realistic doesn't diminish that sensation too much.
If you're trying to do it all in software, you can get pretty far with a function to draw a solid colored triangle, a function to rotate 3d points using sin and cos, and some loops. Then the other pieces like lighting and texture mapping can be added pretty incrementally (depending on how obsessed you are with optimization).
You may like my https://github.com/pjc50/ancient-3d-for-turboc : a slightly more modern target than the NES, it targets Borland Turbo C for MS-DOS and renders to the standard game 320x200 paletted "mode 13" display.
Standard techniques of the time; project the 3D to 2D, cull backwards facing polygons, "painter's algorithm" (draw deepest first, in this case by object rather than by individual polygon).
> I tried to follow a book on writing a ray-tracer from scratch
May I pimp my own book about 3D rendering, covering both rasterization (including 3D projection) and ray tracing? There's a complete, free version at my website, https://gabrielgambetta.com/cgfs
I was just thinking of this book as a recommendation to the parent post, and here the author himself posts it. For what it's worth, I can totally recommend it. I had written rasterizers in the past but not ray tracers until I went through this one weekend.
As a pro game dev in my past life, I promise you can get a 3D engine up and running from scratch in relatively few lines of code. Especially something like a wireframe cube that you can rotate.
> Microprose had 3D flight simulators going back to 1984 on Atari 400/800, Commodore 64, and IBM PC. That's really impressive.
They weren't the only one though. Sublogic also had Flight Simulator II for those platforms. Which wasn't really combat focused (except for the sopwith camel minigame with the checkerboard and the cardboard mountains - lol). But it was also really impressive on such constrained platforms. Ok, it did about 1 frame per second and only rendered in wireframe on the Atari, but you could tune VOR and ADF radios, set weather etc. It was really impressive for an 8bit machine with 64kbyte.
Sublogic later licensed their product to Microsoft to port it to PC which became Microsoft Flight Simulator. And the rest is history :)
It was a bit weird because on the much more capable Amiga there was a flightsim game that wasn't even able to draw a tilted horizon if the gradient function was turned on. I forget which game it was, I think it might have been F-29 retaliator.
Wow... bookmarked. F-15 Strike Eagle II is one of those games I played the hell out of as a child. So much so I wore out two joysticks that my parents bought as a result.
I was a child so it took me a long time to learn to actually do what the game wanted, and then learn after taking out the targets you got more medals by then bombing or strafing other targets. I don't think I ever got the hang of landing back on the aircraft carrier though.
F-19 was my first flightsim (well, some on the Commodore 64 I never got the hang with were the actual first).
I had a pirated copy. Back then, nobody own legit games in my country. It was hilarious that the copy protection gave you a top down view of an aircraft and made you look up the name in the manual.
Yeah... for me, an aircraft-obsessed teenager who knew all the shapes, this was the same as no copy protection at all :) If anything, it trained me in recognizing the shapes of all aircraft of that era!
PS: I was sad when I learned the F-19 was never a real thing. That said, sometime later MicroProse came up with the F-117, which we know was a real thing.
I owned multiple Microprose games and the manuals that came with the games were simply fantastic.
There would be a section on the gameplay itself and then usually some historical reference about the setting of the game. E.g. if it was a WW1 flight combat simulator, there would be a section on the history of aerial dogfighting and then specs on each plane.
I know that nowadays it's common knowledge that most people don't read the manuals and it's easier to get people into a game with a combination first level /introduction/tutorial. That being said, I feel like we lost something by taking out the manuals with all that rich historical detail.
Not this game, but DOS game + reconstruction made me think about something from my childhood.
I used to get around 1h of Internet time (modem) per week. I used this to download stuff that I could use for the rest of the week.
One time I started downloading a game, but a bit too late so I never got to finish the download before my time was up. Of course the game would not work as it was only partially downloaded (IIRC it was a zip file, but not 100% sure).
There was some message from Windows telling me that there was something wrong with the exe. But I continued trying to open the game over and over again (maybe fiddled with the properties?) and one day it magically started, ran for a while and then crashed. It was possible to restart it, but it would crash at the same point every time.
It's still a mystery how it was possible, I guess it only had "content" left and the exe itself was fine, but that doesn't really explain why Windows initially refused to start it.
The page "What does it take to take an old game apart? (Part 3)" mentions the 'restunts' project to reverse-engineer Stunts / 4d Sports Driving, and finding limited information about it.
Me too. My first “hacking” experience was loading the save files into a hex editor and flipping bits to award medals and ranks. I still win every the old way too. Bombed the heck out of Baghdad.
Readit News
The combination of janky PC hardware, paper-thin MS-DOS operating system and prehistoric development tooling makes for an environment where anything goes. Real mode segmented memory and large memory models utterly confuse Ghidra's analyzers and decompiler, most common modern reverse-engineering tools either do not support 16-bit MS-DOS executables or have third-rate support.
It is more art than science in a way that I don't think reverse-engineering later software can match.
With 256 byte paragraphs, you would have been able to address 16MB instead of 1MB in real mode.
I don't know the first thing about 3D programming. I tried to follow a book on writing a ray-tracer from scratch just to see if I could pick up the principles and do it myself, but I got frustrated by the ambiguity of the approach. Like I was trying to use Ruby with Rspec, but I'm not even sure if I'd run into a performance issue or not be implementing the interfaces correctly.
I just want to know what method was used. Maybe 3D projection?
https://en.wikipedia.org/wiki/3D_projection
Microprose had 3D flight simulators going back to 1984 on Atari 400/800, Commodore 64, and IBM PC. That's really impressive.
https://en.wikipedia.org/wiki/Hellcat_Ace
Kind of like how Myst was able to deliver ultra-high resolution 3D images in a video game in ways that had never been done before, even though it was really just a point-and-click slideshow with embedded videos and scripted interactions (Hypercard)... Hellcat Ace provided an experience far ahead of its time.
F-15 is not pseudo-3d at all.
Flight simulators were early innovators in proper polygon based graphics. Partly because there were so few polygons they could get away with the painters algorithm. Partly because the instrument panel could cover a large chunk of the screen. But mostly because players of flight sims were willing to put up with very low frame rates, even 1 frame-per-second would be considered playable for certain types of flights.
Anyway, the tricks used for the 8 bit computers and consoles were nothing more than distilling down the graphical complexity until all they really had to draw was a tilting horizon line and then use a few sprites for everything else.
The one notable pseudo-3d technique I'll point out is the voxel based terrain used by "Comanche: Maximum Overkill". That's well documented.
Speaking of those machines, I'd love to see someone deeply reverse engineer the pseudo-voxel/fractal landscape engine that Lucasfilm Games invented for Rescue on Fractalus, Koronis Rift, etc. It still seems completely magical that they could pull that off on a machine with those specs.
Starting from zero, you might start at a high level and work your way down. Do a simple polygon flight engine using OpenGL and your favorite high level language of choice. Then write your own polygon rasterizer that you can overlay versus the OpenGL rendering as a reference. Then maybe rework it in pseudo 8-bit code (C constrained to only unsigned char variables, or similar), which should translate directly to assembly language on the target of choice. On a real 8-bit machine, unless you want low single digit frame rates, you probably have to pull a lot of dirty tricks. Maybe a 16-bit platform would be a better choice. This is speculative - I learned 3D (to a novice degree..) on a 486 PC under 16-bit DOS using C and assembly for inner loops (bitblts, texture mapping).
There's something about the aesthetic of late 80s PC flight sims (F-19 Stealth Fighter, LHX Attack Chopper, etc.) and their flat shaded polygon graphics that feels in vogue right now. Check out Thunder Helix on Steam.
Anyway there's definitely a magical feeling writing graphics code when you get your first feeling of realistic movement and rotation in 3D space working. Hopefully the ubiquity of ultra-realistic doesn't diminish that sensation too much.
There are lots of interesting pages about this. Here's a contemporary one that comes to mind: https://www.modeemi.fi/drdoom/3dica/3dica.htm
An easy way to get your pixel color array on screen is SDL2: https://www.libsdl.org/
Standard techniques of the time; project the 3D to 2D, cull backwards facing polygons, "painter's algorithm" (draw deepest first, in this case by object rather than by individual polygon).
> I tried to follow a book on writing a ray-tracer from scratch
The hardware of the time would ray-trace at multiple hours per frame. See https://github.com/POV-Ray/povray
There's also various article series in the flipcode archives: https://flipcode.com/archives/articles.shtml
You can also find the source code on archive.org if you don't feel like typing everything.
https://pikuma.com/courses/learn-3d-computer-graphics-progra...
As a pro game dev in my past life, I promise you can get a 3D engine up and running from scratch in relatively few lines of code. Especially something like a wireframe cube that you can rotate.
They weren't the only one though. Sublogic also had Flight Simulator II for those platforms. Which wasn't really combat focused (except for the sopwith camel minigame with the checkerboard and the cardboard mountains - lol). But it was also really impressive on such constrained platforms. Ok, it did about 1 frame per second and only rendered in wireframe on the Atari, but you could tune VOR and ADF radios, set weather etc. It was really impressive for an 8bit machine with 64kbyte.
Sublogic later licensed their product to Microsoft to port it to PC which became Microsoft Flight Simulator. And the rest is history :)
It was a bit weird because on the much more capable Amiga there was a flightsim game that wasn't even able to draw a tilted horizon if the gradient function was turned on. I forget which game it was, I think it might have been F-29 retaliator.
Deleted Comment
I was a child so it took me a long time to learn to actually do what the game wanted, and then learn after taking out the targets you got more medals by then bombing or strafing other targets. I don't think I ever got the hang of landing back on the aircraft carrier though.
I had a pirated copy. Back then, nobody own legit games in my country. It was hilarious that the copy protection gave you a top down view of an aircraft and made you look up the name in the manual.
Yeah... for me, an aircraft-obsessed teenager who knew all the shapes, this was the same as no copy protection at all :) If anything, it trained me in recognizing the shapes of all aircraft of that era!
PS: I was sad when I learned the F-19 was never a real thing. That said, sometime later MicroProse came up with the F-117, which we know was a real thing.
There would be a section on the gameplay itself and then usually some historical reference about the setting of the game. E.g. if it was a WW1 flight combat simulator, there would be a section on the history of aerial dogfighting and then specs on each plane.
I know that nowadays it's common knowledge that most people don't read the manuals and it's easier to get people into a game with a combination first level /introduction/tutorial. That being said, I feel like we lost something by taking out the manuals with all that rich historical detail.
I used to get around 1h of Internet time (modem) per week. I used this to download stuff that I could use for the rest of the week.
One time I started downloading a game, but a bit too late so I never got to finish the download before my time was up. Of course the game would not work as it was only partially downloaded (IIRC it was a zip file, but not 100% sure). There was some message from Windows telling me that there was something wrong with the exe. But I continued trying to open the game over and over again (maybe fiddled with the properties?) and one day it magically started, ran for a while and then crashed. It was possible to restart it, but it would crash at the same point every time.
It's still a mystery how it was possible, I guess it only had "content" left and the exe itself was fine, but that doesn't really explain why Windows initially refused to start it.
There's actually a small group working on it, and more details here: https://forum.stunts.hu/index.php?board=90.0
Disclosure: I manage the forum where the discussion is happening, I'll need up my SEO if the author could not find it :P