Page 2 of 2 FirstFirst 1 2
Results 11 to 20 of 20

Thread: How does it work? And why is it slow?

  
  1. #11
    Ghost
    Join Date
    Dec 2010
    Location
    Madrid, Spain
    Posts
    368

    Default Re: How does it work? And why is it slow?

    Yes I know, but this only requires lot of time (and lot of knowledge), but can be done, it is not impossible

  2. #12
    Mistress kyle's Avatar
    Join Date
    Sep 2009
    Location
    Scotland
    Posts
    936
    Gamer IDs

    Gamertag: FOG I Kyle PSN ID: CreamedCustard Steam ID: kylemotherwell

    Default Re: How does it work? And why is it slow?

    Quote Originally Posted by P_Hansson View Post
    I don't want to guess on a percentage here, Mefistotelis may have an answer since he's the one that has rewritten near everything.



    Examples of rewritten areas: Hardware interfaces (graphics/mouse/keyboard/audio), a lot of gameplay code, the frontend interface, and so forth.



    The problem is more the game to become "portable", it must be 100% rewritten, which may never happen. Regarding "faster": Although technically the new code probably executes faster because of improved compiler technology, it doesn't matter at all in this context, since new computers do not have a problem with the amount of computation a game from 1997 requires. Unfortunately, because of some hardware problems, some things we change may actually cause game to lag (that has been the case for the new SDL version for some users).



    All of those, minus graphical improvements for now. I'm adding stuff that weren't in the original: TCP/IP networking, voice commands, a different kind of AI, etc.



    Potentially. The thing is, doing such a thing would completely change the feel of the game. It would have to be optional to activate new graphics. Therefore I have not prioritized it and will not do so in the foreseeable future, although I'm becoming increasingly convinced it would be possible. (Because of how many of the game data structures are now exposed in C.)
    You know, syn redone the textures in high definition, you could possibly use those and everything would look sharper, of course it should still be an option but thats probably the easiest way.

  3. #13

    Default Re: How does it work? And why is it slow?

    Quote Originally Posted by jomalin View Post
    Why will this be never happen? It is OK if this take a long time but I think someday it will be finished, isn't it?
    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.

    Quote Originally Posted by kyle View Post
    You know, syn redone the textures in high definition, you could possibly use those and everything would look sharper, of course it should still be an option but thats probably the easiest way.
    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.

  4. #14

    Default Re: How does it work? And why is it slow?

    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.

  5. #15
    Ghost
    Join Date
    Dec 2010
    Location
    Madrid, Spain
    Posts
    368

    Default Re: How does it work? And why is it slow?

    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

  6. #16

    Default Re: How does it work? And why is it slow?

    Quote Originally Posted by HSovieticus View Post
    Someone needs to get a job at blizzard and maybe "misplace" the source code.
    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).

    Quote Originally Posted by HSovieticus View Post
    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?
    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.

    Quote Originally Posted by HSovieticus View Post
    Is playing the game the only way you can compare the new code to the old code?
    Not sure what you mean here. Compare, in what way?

    Quote Originally Posted by HSovieticus View Post
    So have you guys thought of using an open source game engine like crystal space or the blender game engine...
    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.)

    Quote Originally Posted by jomalin View Post
    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
    Agreed.
    Last edited by p_hansson; February 5th, 2011 at 02:53.

  7. #17

    Default Re: How does it work? And why is it slow?

    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?

  8. #18

    Default Re: How does it work? And why is it slow?

    Yes, and like I also said, it is not simple.

  9. #19

    Default Re: How does it work? And why is it slow?

    I'll take your word for it then.

  10. #20
    Ghost
    Join Date
    Dec 2010
    Location
    Madrid, Spain
    Posts
    368

    Default Re: How does it work? And why is it slow?

    Quote Originally Posted by P_Hansson View Post
    Yes, and like I also said, it is not simple.
    Searching in KeeperFX 0.38b source code for "field_" gives 6537 matches! So there are a "few" variables to be properly renamed (and understand first). In fact, too much work!

Similar Threads

  1. Fixing Slow?
    By Mothrayas in forum KeeperFX
    Replies: 4
    Last Post: September 26th, 2022, 19:55
  2. [0.38] Debugger extremely slow?
    By Krizzie in forum KeeperFX
    Replies: 12
    Last Post: February 4th, 2011, 09:06
  3. The game runs very slow
    By kyle in forum KeeperFX
    Replies: 2
    Last Post: December 18th, 2009, 17:29
  4. How i got dk1 to work on vista
    By ryanxsh in forum Dungeon Keeper 1
    Replies: 15
    Last Post: December 10th, 2009, 04:32

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •