Hat er den Original Code decompiliert, oder wie kann er behaupten er hätte jetzt sowas wie den Original Code?
Im Kommantar bei der Originalmeldung stehts. Ist für mich aber zu hoch
.gif ":) :)")
So people here might be wondering how this was actually done.
Computer programs are normally published as executable code - the stuff a processor actually executes, essentially just a series of numbers. For instance, on Intel/AMD processors, a byte of “3" means “add the contents of the register or memory address specified by the next byte(s) to the register or memory address specified by the byte(s) after that, and stick the result into that first register or address”. This is basically unreadable by humans. Nobody’s written code that way in at least fifty years.
We can use a relatively simple program, called a disassembler, to start turning that executable code into something a bit more understandable. This gives assembly code - essentially just turning those arbitrary numbers into text. That “3" might turn into “add eax, ebx”. This still doesn’t tell us what that addition is trying to accomplish - is it figuring out how much HP you have after leveling up? is it moving a character around? is it a loop counter in a draw routine? In the very old programs which were directly written in assembly, there would at least be comments describing the purpose, but that’s removed in the process of turning assembly code into executable code. And nobody’s written serious programs directly in assembly code in probably twenty years, save for really, *really* low-level operating system stuff.
The next level up from assembly language is a high-level language like C++, which is what Diablo used. This is halfway between a human language and math - code tends to look like “player.maxHP = 100 + player.level * player.class.hpPerLevel;”, at least when humans write it.
Executable code has no use for those labels anymore. After all, the computer doesn’t need to know that the programmer called it “maxHP”, all the processor needs to know is what memory address it’s in, and that’s just a big number. While there are programs to try to turn assembly back into high-level code, it normally can’t even guess at names. So you wouldn’t get “maxHP”, you’d get “l164926" or something.
However, there are cases where those names *will* get crammed into the executable code. Specifically, things called debugging symbols. This is used by debuggers, tools used by programmers to figure out why their program isn’t doing what they want. At their simplest, they let you pause the program, see what line of code it’s currently on, see what all the variables are set to, and then step through it line-by-line until you realize how you messed up. And to do this, they clearly need some sort of way to map what the processor knows (“I am about to execute the instruction starting at address 0xA842EF70") to what the programmer knows (“I think there’s a problem in the function renderPlayerShadow()“). So, in a debug build of the program, that data gets shoved into a section that’s never directly executed, but which the debugger knows to look at.
That’s wasted space in a final, retail build, and it actually can slow the program down a tiny bit, so normally the executable that gets sent out has that debugging info removed. But, apparently, there’s a few copies of Diablo.exe that didn’t have those debugging symbols stripped out - some from a Playstation port, and a partial debug build accidentally packed into a data file on the PC version.
By piecing things together, we now have a somewhat-readable equivalent to the original code. It is*not*actually the original code - the original comments (notes left by the programmers to explain what “AutoMapPosBits = (AutoMapScale << 6) / 100;” actually does) are completely gone, and not everything had a debugging symbol. If you look, you’ll still see plenty of variables with names like “int v25", not very useful.
But it’s close*enough. Once you compile it back into executable code, it will work the same, and enough is labeled and named sensibly that a good programmer will be able to figure the rest out, and build on it. I expect there will be ongoing work to clean up the remaining cruft
Zum Artikel: Diablo: Hobby-Entwickler rekonstruiert das RPG in vier Monaten
