Hacker News Reader

Comment by taffydavid | Hacker News Reader

Noob question. I really hope this doesn't come across as negativity.

I love that people spend time on making old games work, but why do people decompile games that can be emulated by DOSbox or the like? Surely a game this old runs absolutely fine on even very low end hardware?

View on HN

It's not about running the game, it's about having it open for modification. Patching a game in binary form is ridiculously hard, anything than simple bugfixes is mostly a no-go. With the source code available we can add entire features, port it to Windows 10, implement 4K HDR, textures, new models, new missions... the sky's the limit. Additionally, it's really hard to analyze the game from assembly opcodes with hardcoded data offsets. With C code either we can read what it does directly, or add instrumentation or debugging code to it to figure it out.

And personally, I prefer doing ./game, rather than having to install a bunch of stuff and see my system cluttered by hidden folders.

Ok but - and again I'm trying not to be negative, simply trying to understand - if you want a flight sim that works on Windows 10 and supports 4k HDR, wouldn't it be a lot easier to just build it from scratch, rather than trying to decompile a game from 1989 that came on 5¼ inch floppies? I mean, even if someone just _gave_ you the source code of the 1989 game it would be more work to port it to Windows or as a feature than it would be to just build your own 90s era air combat game in c++ without any baggage.

Is it simply about squeezing more out of a classic game we love?

be negative, no problem - the goal is different - we are foremost developers that like the challenge to get the game back into its source state - its interesting to see on an algorithmic level how the devs got it working at that time with all this hardcore constrains (It's like the joy of an archaeologist unearthing an old wooden tool.) - for many developers gaming was the startpoint of interest in software development, and reversing is the gold-class, all your life long expirience needs to be on point to be able to reach such a goal, maybe hard to understand for non-developers - and only a few people on the world are able to do that (even with LLMs) and developers praise these ones :)

For an example of what a "finished" product of this work looks like, check out Cannonball at https://github.com/djyt/cannonball/wiki, an Out Run remake preserving the original game logic.

I could do you one better, if I just wanted a flight sim that works on Win10 with 4K HDR, I could just install DCS with the F15 module from Steam and call it a day. ;) I just happen to love this particular game, and would like to see it transcend its limitations. I am also an enthusiast of MS-DOS and early x86 hardware, so digging through all that stuff is pure joy for me, and I don't see it as "work" or "baggage".

A lot of floppy-based games have on-disk copy protection patterns that take advantage of undocumented behavior of disk drives at the time. So much so that tools like Greaseweazle [0] are necessary to compose full magnetic flux maps of archived floppies.

Another thing is that these games are often made to run on a wide variety of graphics and sound hardware, and effectively have drivers compiled into them.

[0] https://github.com/keirf/greaseweazle

I had a few reasons, when I tried tackling RE of a DOS-era game a number of years ago. I wanted to document the file formats, look through the data and find unused media, identify and fix some of the more egregious bugs in the game, build modding tools for it, understand the techniques used to build something that was memorable from my childhood, reduce the friction of running it on a modern system, make available optional improvements like higher resolution, texture replacement, and so on.

It ended up being more than I had the patience to finish. It might be doable for me now.

Reply on news.ycombinator.com