Nostalgia is a funny thing. If you experienced the early days of video games in the 1980s and 90s, there’s a good chance you remember those games looking a whole lot better than they actually did. But in reality, the difference between 2023’s Tears of the Kingdom and the original Legend of Zelda is so vast that it can be hard to reconcile the fact that they’re both in the same medium. Of course, that doesn’t mean change the way playing those old games actually makes you feel. If only there was some way to wave a magic wand and improve the graphics of those old titles…
Well, if you consider Ghidra and a hex editor to be magic wands in our community, making that wish come true might be more realistic than you think. As [Alberto Marnetto] explains in a recent blog post, decompiling Stunt Island and poking around at the code allows one to improve the graphical detail level in the flight simulator by approximately 800%. In fact, it’s possible to go even higher, though at some point the game simply becomes unplayable.
Even if this is the first time you’ve ever heard of this particular 1992 flying game from Disney, the write-up is a fascinating read and contains some practical tips for reverse engineering and debugging older software from within the confines of DOSBox. By strategically setting break points, [Alberto] was able to follow the logic that reads the desired graphical detail level from the configuration file, all the way up to the point where it influences the actual rendering engine.
It turns out the detail level variable was capped off, but by studying the way the engine used that variable to modify other parameters, he was able to tweak the math from the other side of the equation and go beyond the game’s intended 100% detail level.
Looking at the side by side comparison with modern eyes…even the tweaked version of the game leaves a lot to be desired. But there’s only so far you can push the engine, especially given the limited resolution it’s able to run at. But there’s no question that the patch [Alberto] has developed greatly improves the density of objects (buildings, trees, etc) on the ground. The video below shows off the patched game running at full-tilt to give you an idea of what it looks like in motion.
This isn’t the first time we’ve seen an enthusiastic fan patching new capabilities into their favorite retro game. From the upgrades made to Mortal Kombat Arcade Edition to the incredible work [Sebastian Mihai] put into creating a custom expansion to Knights of the Round, you’d be wise not to underestimate what a dedicated gamer can pull off with a hex editor.
Thanks to [adistuder] on the Hackaday Discord server for the tip.
I remember playing Flight Simulator on a PC XT. Also on a DG/One. The original, not sure if it was Sublogic or Microsoft, but I do remember the Sublogic name on it. DG used it as a compatibility test for the DG/One. If it ran Flight Simulator, it could ship (so there were a lot of disks floating around DG when I worked there).
For what it was running on, I thought it was pretty damn good. Tetris took up most of my time though.
Now I run X-plane, because I’m not giving Microsoft a penny if I can help it.
Speaking of Flight Simulator, version II for Amiga was notable.
It had both a higher color depth (32c vs 16c) and resolution than the other ports.
MS Flight Simulator 4 had full EGA (640×350 16c), full VGA (640×400/640×480 16c) and Super VGA support (800×600 16c), too.
A far cry from “toy” simulators stuck in 320×200 resolution (even mode 13h could be tweaked; 320×400 and 360×480 were possible on stock IBM VGA).
More information (not by me):
http://shot97retro.blogspot.com/2020/06/flight-simulator-ii-in-depth-amiga.html
https://gekk.info/articles/msflight4.html
Last but not least, it’s a shame that nearly none of the PC flight simulators had made use of the x87 coprocessor in some way.
Yes, it was an optional unit until 486DX, but it surely was possible to compile the game twice and put a separate EXE with x87 support on disk.
(And after about 1990, the older NPUs for 808x PCs had dropped in price a lot. So users of old PCs had an even greater use for x87 support than a fancy 386/486.)
Considering the average executable was 200 KB in size, that wasn’t too much disk space being wastet.
Also, x87 did support both floating point and integer math.
Whowever had used AutoCAD before knows how good NPUs can be at calculating vectors.
I don’t remember for certain if it was an Apple II (I had multiple computers at the time), but that was the slowed Flight Simulator experience ever. The frame rate was really slow, probably not more than 2 per second. The dog fight was quite something. PC/XT was just a little faster.
I believe MS eventually bought Sublogic for the flight sim.
Yeah it sucked, but not nearly as bad as flight sim on an apple 2 or trash 80.
In those the enemy plane was 1 pixle and the world looked like Battlezone.
Using AI to revamp old games is already a market trend. But using a hex editor is much cool and nostalgic.
AI is terrible. Actually understanding what you are doing instead of trusting conversational Google is the correct way.
AI is a tool and like all tools it has good and bad applications. I personally find it helpful to get me started on something I am a newbie at or something I do not care about the quality of. Is it as good as an expert with 30 years experience no but if I just need something “good enough” AI often can make that.
Using AI tools like personal tutors as predicted by Neal Stephenson in “The Diamond Age”.
“but [..] I just need something “good enough””
short description of the downfall of modern civilization right there
the first people who use AI, it’s good enough because it’s trained on everyone who didn’t use AI
the next people who use AI, it’s a little less, because it’s trained on fewer people who didn’t use AI
…
Eventually you’re left with nothin’.
Someone famously polluted Wikipedia with a fake inventor of the toaster, and it spread everywhere. But with Wikipedia you could at least trace it back. When people start polluting AI models with information that you can’t easily prove wrong, it’ll literally be untraceable. It’ll just be information that’s wrong. Everywhere.
Wikipedia isn’t the bastion of truth. They always want you to cite anything with some sort of article.
They completely reject the idea of the voice of person present at historical moments.
I’ve written articles related to the specific history of computing because I was literally in the room and they’ve been rejected/deleted in mere hours because I cannot link to a webpage.
Wikipedia editors are controlling history and the version of it that we are allowed to read.
Wikipedia will produce ‘truth’ from nonsense if it’s just left up for a minute.
Someone else will cite wiki and put up a page.
The next week Wikipedia will cite that.
All that’s required is a ‘circle of nonsense’.
Sorry, just report your comment without intention!
In TFA the author does try asking an LLM if it can tell him what the freshly decompiled code is doing. He leanrs nothing of use and moves on.
Acorn Aviator FTW!
Now lest see one of Corncob 3D
“It’s the same picture.”
Understable. There are more bushes (trees) though. Objects in the distance are rendered now sooner, too.
That being said, it would be more noticeable if the game ran in 640×400 256c (VBE mode 100h).
That’s four times the pixels (2×2). With that resolution, the increased detail level could be enjoyed actually.
Unfortunately, that issue is not the fault of the hacker/modder here.
He/she did a good job. It’s simply that programmers of the time were obsessed with easy to use mode 13h, thought it would be good enough.
To really take advantage of things the game would need to be dissassembled, converted from MCGA to VBE through hand written assembly code and assembled again.
With VBE 2.x, a linear framebuffer could be used, even. Which would provide better performance on 486/Pentium PCs with 32-Bit graphics cards that had LFB support (PCI, some VLB).
I am fascinated by the fact that at the time, we barely could do basic shapes on a a screen as 3D, yet they were aircraft like the B2 bomber. How did they manage everything? How was it possible?
Control systems are much less computationally difficult than 3d rendering.
Duh.
Oh, there had been sophisticated 3D flight sims dating back to late 70s!
It’s just that home users had weak computers at hand.
In the professional fields there had been powerful graphics workstations since the early 80s, at least. SGI comes to mind.
Also, these flight sims for PC weren’t being optimized yet.
Not too much, at least. They stuck to 16-Bit Real-Mode code (plain 8086 level).
Minimum requirements often did mention an PC/XT or AT.
So 8088 and 80286 processors and CGA/EGA/VGA graphics were supported.
In principle, though, the 80386 was available since 1985.
The Compaq Deskpro 386 had introduced it for AT compatible PCs.
There also was OS/2 available in graphical form from 1987 onwards.
If the flight simulators had been compiled for 80386 instructions, maybe with 32-Bit Protected-Mode code, even, then the 3D graphics could have been more impressive.
There also were the co-proccesors in the late 80s, such as Weitek/i286/i387.
And advanced graphics standards like 8514/A and TIGA.
Alas, 386 PCs were still considered kind of high-end until the 486DX got popular in early 90s,
so DOS games had to try to keep support for older PCs.
Home users were notoriously cheap on money, after all.
In late 80s/early 90s, some users still had bought 8 MHz Turbo XTs, for example.
Everyone knew they were technological obsolete, but they could be made so cheaply now!
The integration process was advanced enough to build a complete XT compatible PC with just a handful of parts.
The problem wasn’t technology, really.
The real issue was acceptance or adoption rate of the technology.
People back then had to be convinced to invest in powerful hardware.
Another issue was that people didn’t know what’s next.
In the 90s, technology was advancing so fast that people hesitated to get the latest tech right now.
They rather delayed purchase for a better deal, so to say.
There was this joke that a PC you had bought was obsolete in the moment you’ve left the door of the store. 😆
That’s also the reason that the minimum requirements and the recommended requirements were so much apart, I think.
If you want to see an graphical sophisticated flight simulator, please have a look at Flight Unlimited from mid-90s, for example.
It’s meant for a 66 MHz 486 PC runing DOS, but supports sound cards and Super VGA graphics.
https://www.youtube.com/watch?v=yha2P9uPleQ
https://www.mobygames.com/game/806/flight-unlimited/screenshots/
The 486DX2-66 was the sweet-spot for many DOS games back then.
Except first-person shooters, I mean. They always needed the fastest there was.
Last but not least, it shouldn’t be forgotten that Macintoshs with an 68040 or Power PC processor were once usable for gaming, too.
After Atari ST and Amigas were gone in early 90s, popular games had been available on both DOS/Windows and System 7.x.
The Macintosh games did tend to support 640×480 256c as a minimum resolution when DOS games still had 320×200 256c as standard.
So it’s wise to not limit ourself to PC history here or assume that PC tech was leading edge,all the time.
At some point, the ports or remakes for Macintosh had better graphics for a while (some worse examples had used upscaled graphics, sadly).
Just have a look at Prince of Persia, Sim City or MS Flight Simulator 4 for Mac.
The had graphics either on eye level with their PC originals or had graphics that surpassed them.
Last, but not least, there Japanese systems such as PC-9821 or Sharp X68000 who had higher resolution graphics.