> I had to find names that would allow the variables to appear in the correct order. So after some trial and error, I wrote a small throw-away program that generated a bunch of variables with random names and ran that list of variables through the Turbo C++ compiler. Disassembling the generated .OBJ file showed me which order these variable names would produce
Nice puzzle!
Is the ordering the only thing that can be recovered from the binary? If the hash is available anywhere, it should be possible to brute force the exact original names.
> They used the same routines they wrote for their day jobs at Softdisk in the Keen code. [...] Most of the IDLIB.C code must have come directly from the PC version of Dangerous Dave. [...] there is some extremely strong evidence showing that the id founders used Softdisk's code in their own game. Sure, it's not the code responsible for the smooth scrolling, but it is code they probably didn't have the rights to use.
Huh, this is interesting. Is someone able to provide more detail?
The pace at which Id produced games has always been an inspiration for me. Large amounts of code reuse seems like an important clue as to how they were able to do that.[1] But how were they able to reuse code effectively to such a degree?
[1]: The other clues I have so far are Romero's legendary tool-making abilities, and Carmack's tendency to produce code that gets computers to do things they couldn't before.
I'm pretty sure that it's not exactly about the code, it's a case of having honed skills and techniques from multiple different sources - John Romero was bouncing around the industry and working on both larger and smaller productions, multiplatform ports, and different approaches to engine/content(he got his hands on both Origin's and Infocom's stuff, as well as a few other places) - the number of references he brought to the table could not be underestimated. John Carmack didn't have that same experience but would have been able to take a description from Romero of "at Origin we did it like this" and aim to make a very efficient version of it - his growth into borrowing academic research for inspiration came a little later. And there was also the early influence of Tom Hall who was older, able to communicate what he wanted as a producer and probably steered the programming team away from wrong turns a few times.
When you have the experience, you already know how long it takes to implement the majority of the game, when we're speaking of these early 2D games using bitmaps, tiles, small animations and some monospace text. The gameplay code is game-jam sized in most instances, so a majority of it was I/O code and asset pipelines. You can chart a safe course to get through one tiny project, and then another, and another, and build a best-of the routines that worked. The coding style would be assembly-like at this time even if they were using C - no deep callstacks, mostly imperative "load and store", which allows for a lower level form of reuse than is typical these days by breaking down the larger algorithm into "load", "mutate", "mutate", "mutate", "store" each as separate routines. So you end up with some tight code when you get to run it through a lot of projects. Softdisk provided the opportunity for building that and getting paid.
11 comments
[ 3.1 ms ] story [ 37.6 ms ] threadNice puzzle!
Is the ordering the only thing that can be recovered from the binary? If the hash is available anywhere, it should be possible to brute force the exact original names.
Huh, this is interesting. Is someone able to provide more detail?
The pace at which Id produced games has always been an inspiration for me. Large amounts of code reuse seems like an important clue as to how they were able to do that.[1] But how were they able to reuse code effectively to such a degree?
[1]: The other clues I have so far are Romero's legendary tool-making abilities, and Carmack's tendency to produce code that gets computers to do things they couldn't before.
When you have the experience, you already know how long it takes to implement the majority of the game, when we're speaking of these early 2D games using bitmaps, tiles, small animations and some monospace text. The gameplay code is game-jam sized in most instances, so a majority of it was I/O code and asset pipelines. You can chart a safe course to get through one tiny project, and then another, and another, and build a best-of the routines that worked. The coding style would be assembly-like at this time even if they were using C - no deep callstacks, mostly imperative "load and store", which allows for a lower level form of reuse than is typical these days by breaking down the larger algorithm into "load", "mutate", "mutate", "mutate", "store" each as separate routines. So you end up with some tight code when you get to run it through a lot of projects. Softdisk provided the opportunity for building that and getting paid.
Carmack was a genius.
This is released under GPL.
I wonder, who is K1n9_Duk3? Does he have the rights to actually release this, and put it under GPL?
What does "reconstructed" mean? Is this disassembled? And if so, is it really ok to put this under GPL then?