Yes I know, but this only requires lot of time (and lot of knowledge), but can be done, it is not impossible
Yes I know, but this only requires lot of time (and lot of knowledge), but can be done, it is not impossible
Because it takes insane amounts of time to reverse-engineer everything. In the same amount of time, I could be programming a game from scratch. The only reason to do it is because we want this to be Dungeon Keeper, and not something else.
May never happen = people tiring on re-writing code. Especially likely to happen if only code which isn't useful to reverse in any way remains.
It's not necessarily easier. The thing is, if writing a new renderer from scratch, not much more code must be reverse engineered. If textures are to be replaced in the existing renderer, all the code in the existing renderer which pertains to said textures must be rewritten (because of what textures are used and texture size are probably hard coded some extents). I believe this is the reason why Mefistotelis hasn't enabled higher quality textures already. The DK renderer is more complex than you might believe, given that it's implemented in software (rather than being a hardware interface).
Last edited by p_hansson; February 4th, 2011 at 19:11.
Someone needs to get a job at blizzard and maybe "misplace" the source code.
Seriously though, is there not a program you can use to convert the original game code, which I assume is binary, into something more intelligible?
Is playing the game the only way you can compare the new code to the old code?
As for replacing the renderer (and I assume that "renderer" means more than just the API; ie. OpenGL, Direct3d, SDL): It seems as though a new renderer would make the game much more compatible/portable and also more efficient. So have you guys thought of using an open source game engine like crystal space or the blender game engine? Getting the game engine to use the dll shouldn't be much harder than it was to write the existing executable which uses the dll, right? And I would think that rewriting all that has already been rewritten should not be as hard as it was to rewrite it the first time. Or maybe not, as it would probably be fairly different. You would be writing code to integrate the dll into the new game engine, to synchronize or connect the game mechanics in the dll to the rest of the game (graphics, frontend interface, and hardware interfaces) which would be recreated in / replaced by the new game engine. As opposed to recreating the original game engine (minus the game mechanics) from scratch. Although you are able to isolate and rewrite one function at a time, it is mostly guesswork (as I understand it) since you do not have access to the original source code, nor do you have access to any kind of documentation. I might be wrong, and I'm just guessing, but I would think that using a good open source game engine to handle the graphics and user input might be easier than rewriting and improving those things from scratch. You would still need to modify the game engine to use the dll in the right way, similar to how you are writing the executable to use the dll, but if your goal is to make dungeon keeper work on a variety of modern systems as well as it worked back in 1997, maybe even better, wouldn't it be easier to use an engine that already works like that, and then modifying it to make use of the dll for things that should not be changed (and, of course, for things that have yet to be changed)?
Last edited by HSovieticus; February 4th, 2011 at 21:37.
That's true, reverse engineering a game tooks insame amount of time, as an example, there was a spanish game called "La abadia del crimen" for msdos. Some years ago, a programmer dissasembled the game and ported it to win32 C code, with 256 color palette graphics enhacement and some graphics effects (shadows, lights, etc), that takes him 4 YEARS... The final work he brings was magnific
There is an oversupply of game programmers. Finding such jobs is quite hard unless you got a perfectly matching degree, many years of experience or get it via social contacts. (Or do it yourself.) Oh, I'm aware you weren't serious, but yeah.
Btw you could probably implement DK as a mod in Starcraft 2 to a large extent (it's being done as well).
In the general case, no, because C to assembler is a many to many mapping of instructions, and its inverse is many to many. Some of those possible representations are pretty hard to understand. We do use a disassembler which actually produces pseudo-code, but the fact is this pseudo-code is hardly more readable than the assembler it represents. For distance, it can generate code for a C expression like:
game->player[i].money = 128;
into
* (unsigned long *) ((unsigned long) game_field00 + 276582 + (i + 1) * 5574) = 0x80; //(fictional addresses, but this is how pseudo-C output looks)
For the record, I spend a significant amount of my RE-time recalculating addresses to more sensible representations. And if I get a single bit wrong, a new bug is born. Either way, it makes me wonder how long Mefistotelis has spent on it in total.
Not sure what you mean here. Compare, in what way?
Yes, of course. It's not productive to try to write a modern 3D graphics engine from scratch unless you got man-decades of sufficiently skilled work force available.
Even with a fancy high level GFX engine it's a pretty major project and therefore carries a rather large opportunity cost. (The core game can be improved instead.)
Agreed.
Last edited by p_hansson; February 5th, 2011 at 02:53.
Can't you just disable the game's original renderer and then have the instructions on what draw (and where and how) routed to the new renderer instead?
Yes, and like I also said, it is not simple.
I'll take your word for it then.