the best thing about ghidra is that no matter which version you're using, setting equates sometimes just doesn't work, but if you google it, you only find several bug reports which basically say "equates don't work" and then it's "closed, fixed in X.Y.Z" and that's a version you're upgraded way past
the weird thing is the equates table says it's been set, says there's a reference to it at that address, but if I go to that address, there's nothing. just 0x3c4
@foone FWIW, I believe in IDA this kind of thing mostly happens because they want to attach the new name to something in the assembly code, so when the decompiler has introduced the variable, it's often not clear what it should be attached to, and things get weird and broken.
They had the introduction of the gameport listed as "the PCjr" (it's from 1981, the PCjr came out in 1984... and didn't even have this gameport connector!) but more importantly, they had the order of the joystick axises wrong.
and the IBM Game Control Adapter is mentioned in the August 1981 IBM PC Technical Reference, so IBM clearly had the gameport ready at day one of the IBM PC, even if it was an optional add-in.
mind you, on the IBM PC, just about everything is an optional add-in. You get a keyboard and a cassette port for free: you want graphics/text, floppies, hard drives, serial/parallel ports? that's extra.
My first in the house computer was a 386, but I remember the days of not having enough slots/resources and having to fiddle with way too many jumpers/dip switches to get it to all play nice.
@foone The best option, IMHO. Integrating the drive controllers... eh, okay, but other things, it's nice to have them separate. The sound chip on my current board started making Dalek mating calls one day, so I had to disable it, plugged in an Audigy 5/Rx. Been having issues with the two 8TB USB 3.0 drives connected, and might need a new card for that, but I'm out of PCIe slots.
god. Duke Nukem 1 has so much copy-pasted code.
Like, there's a ton of hint dialog boxes like "You need the key to open this door!" or "you get more points if you catch the balloon"
you'd think they'd just have ShowMessage() and pass it a different string, but nope. it's a different function.
@foone when I see stuff like that in really old code I always wonder if it's the bad kind of laziness or if there's some really fucked up restriction they had to work around that drove them to write code that way.
Like writing it the sane way would cause some exceptionally slow memory access or long jump or whatever. Or a crappy compiler or linker would put the string in the wrong place or something...
like, it has a function that loops through all 16 color indices and sets them to black. it takes one parameters, which tells it how long to wait between each color is set, so it'll fade slowly to black, instead of being instant.
there's also an identical function that does the same, but sets it to white, instead.
@foone If it was fading each index (slowly changing to the target, rather than just switching one palette entry at a time), then I could understand making it two functions, as it probably makes the code a bit simpler.
Of course, if it's just:
for(int i=0; i<16; i++) { palette[i] = 0; }
then separate functions are less attractive.
Who said old code was more efficient? :blobcatwink:
The game starts with these two screens.
There's a function to draw Dr Proton, a different function to draw Duke Nukem, a function to draw Proton's text, and another function to draw Duke's
there is some extra code for checking the command line for another code, which I think would be "dn1 asp g" but I'm not sure what it does. something in the keyboard handler, it seems?
I was gonna say that it would make sense if they originally had a save system that let you save anywhere, but not exactly: some stuff is missing that'd let you have a real mid-level save.
it doesn't save your keys or if you have the access card, which means you could be trapped after reloading a mid-level save
but yeah: despite it technically being visible for 32 years, I never noticed that the game doesn't just save which hallway you're in.
It saves where the duke is relative to the hallway, even if not his actual position.
I just loaded two different saves of Duke in the first hallway. Didn't press any other buttons... but he appears in different places!
guess I'll have to find out where it shows the "you can only save in hallways, dummkopf!" dialog and see if there's an if(!in_hallway && !debug_mode)" before it
I found the part where it shows that dialogbox, it was tricky because it was in Dark Code, but I can't find what calls it for presumably exactly the same reason
segmented real mode DOS is so silly.
I know this function is a far call (not a "fall car", as my fingers somehow typed it) so I just need to look for JMP 208e:1bb0, right?
and it loads properly. Nothing about the level state is saved (other than your player position relative to the default camera position), mind you, so there's not really any reason to do this.
Although it does... okay I think I may have figured out why they did this. One moment while I test.
okay I think I know why they disabled mid-level saving:
so, they don't save your position or level state when saving a game, but there IS an exploit: the gun powerup
the gun powerup is unique in that it can be collected multiple times. The game is smart enough to not let you collect permanent powerups again: if you enter the level where you get the jump boots already wearing them, they simply won't spawn
but that's not the case with the gun powerup because you collect up to three of them over the course of the game. The game doesn't know if it should make them appear or not, since you may have gotten a previous one
and if you can save mid-level, your gun powerup state is saved.
So you enter level 4, collect the gun powerup, and save. quit and restore your game. You now have the gun powerup, and you can collect it again, getting you to gun level 3. Save and restore again, and now you're max gun level (4).
and making you save only in hallways avoids this. And the game stores the state of duke in the last hallway: so when you use f10 to restart, it takes you back to the last hallway, but you lose all your upgrades
now I think they could have solved this in another way: make the save function save the state of duke as he entered the level. They already save that for restoring the player when you die
just one of them: The main-hallway hints and Dr. Proton's security-camera taunts? They're literally the same system, with the two sets of text intertwined.
the game selects what message to play based on your current level. on odd-numbered levels, it ends up being a hint message (because those are the hallway levels), and on even-numbered levels, it's dr. proton taunting you
ghidra really doesn't do a great job of handling 32bit pointers in a 16bit real mode program.
The problem is that they're handled as two 16bit integers, not a single 32bit integer.
ugh. I don't know what this function even does but I can already tell that the only difference between two adjacent functions is which pointers they use.
I'm really doubting the function duplications has anything to do with aggressive compiler optimizations because there's one very small function to determine if something is onscreen or not. It's a couple additions and 4 compares. prime inlining material!
it's not inlined. it's far-called from 148 locations
@foone My recollection (I'm old) was that C compilers tended to go overboard with optimization back then, which is why ANSI has so much UB - the compiler makers didn't want to let go, and saw optimization as a way to distinguish themselves from their rivals.
That said, the 'far call to something inlineable' thing was likely to be because optimization happened within the scope of the file the compiler was compiling. If the function you were calling was in different .c file, then it wouldn't get optimized away. The fact it's a far call to that function strongly suggests, to me, that it was. TBH I don't know how current compilers do it, I'd have thought the same applies, as otherwise linking would break but the world's changed a lot in 40 years.
(Please correct me if I'm wrong, I know you do this kind of thing for breakfast, it's just I recall optimization being very, very, controversial during the 1980s, and it affecting the ANSI C standard in very negative ways.)
instead of having a big array called like GameObjects and a big update function that loops through them all, I think there's separate arrays for sodas and turkeys and atomic molecules and flags and footballs and floppy disks and and and
oh god it even does it for static things like doors
apparently every frame it loops through the doors array and checks if the player is standing in front of them and then checks if the player is pushing the up key
I'm now doing some hybrid static/dynamic debugging. I set a breakpoint on the add_score function, then I'm doing stuff to get points, and seeing what function called add_score
@foone As someone who is normally trying to dissect genius-level code where it's like, "oh yes, we developed this unique system to cram 32KB of data into just 1.9KB and by the way we put it in the display memory using this palette trick" I am living vicariously through this documentary of the same kind of stupid shit I used to do when I'd only been programming a few years.
I think that instead of iterating over all the destructable blocks, it instead calls handle_block_hit from every update function when a bullet doesn't hit an enemy, and that function checks if it was a destructable block and gives you points if it was
okay so beating the game doesn't give you 34464, it gives you 100,000 points. It's just not clear because WHOOPS a 32bit integer in a 16bit mode?
does add_score take two 16bit integers or one 32bit integer? who can say?
anyway I think I've found them all and there's 29 mostly-copy-pasted functions for updating all the various objects in the game.
29 arrays.
29 number-of-items-in-array variables
@foone Now I have read all of your comments on this, and I'm glad I couldn't see the mess behind this game while playing it back then. As a programmer, I could only guess that he was inexperienced, and this was his first project.
@foone having recently reverse engineered the entire game logic of Duke 1 myself, this thread was an absolute treat to follow along. Happy to see you're just as baffled by Todd's strange decisions & coding style. 😄
@foone unfortunately not at the moment, as I did this in the context of an upcoming commercial remaster project. But I hope I'll be able to share some things publicly at some point in the future 🙂
@foone I bet they found bugs with save-anywhere at some point and got rid of it. Anything not in the save files might have been added after the save-in-hallway decision occurred.
@foone My guess is that saving outside of the hallway was once planned and then scrapped partway through? Or maybe the loading part was used for playtesting/bugtests?
@foone Maybe the hallway restriction was added after the save system. Or the developers have a backdoor to let them save anywhere. Would be pretty useful for testing.
@foone
Try to determine where in memory stored loaded rooms when they are more then one. I suppose there’s dummy save logic when we’re dumping mem as POD just to file. I've seen this more than once.
@foone ahh satisfying. Mildly interesting that beating the level doesn't put you in a hallway but keeps you in the level, but with all moving stuff, spikes, etc removed or stopped
@foone i actually was wondering that exact situation, I wonder what changed? Be careful to avoid the rockets, below them is no exit (the rest of the level is safe though). There's some weird area above the visible area on the top left too that you can grapple up into...
@foone Is it possible they are generated code somehow? Like a computer instantiating a template function? I'm guessing they weren't using a language with features like that though...
@foone@darkling
Is it possible this is some segmented memory/near/far pointer thing?
Maybe not even the coder did this, but Borland decided to duplicate the function for some reason.
@poeschel@foone At this point, I'm talking out of my arse (I'm not really an x86 person), but it's duplicating a significant amount of code to avoid passing a single (possibly-)far pointer where it could avoid the duplication at the cost of passing one far pointer? Seems like a significant mis-optimisation on the part of the compiler.
Maybe a segment change is massively more expensive than I think it is, but I hope it isn't that bad.
@eniko it's not THAT slow!
especially when none of these are inner-loop things. They're all "draw some text and then wait for the user to push a key" things
@foone hypothesis: one of turbo c’s optimize-for-speed-not-size flags makes it emit a unique function for every call with a different combination of literal arguments?
like, would be weird, but less weird to me than either the copypaste-everything or only-macros-not-functions interpretations.
since godbolt doesnt do turbo c, im gonna have to dig up a copy later and investigate its compile flags.
@foone the best thing about this sort of copy/paste coding is that it means when you have to fix an issue in one function, you have fix it in 37 different places
@foone Makes me wonder, the commonly assumed narrative is that the IBM PC wasn't designed with games in mind, but did they potentially think with its expandability they thought it could be turned into one with the right cards?
Add comment