02-10-2018, 09:51 PM
Damn you guys ar going down a very very old road.
This work has already been done for the most part.
This work has already been done for the most part.
Reverse engineering Diablo v1.09b (last patch)
|
02-10-2018, 09:51 PM
Damn you guys ar going down a very very old road.
This work has already been done for the most part.
Hej Vortex!
I always feel happy to hear someone else interested in reversing Diablo 1, just for the joy of learning how the game engine works! Quote:Does anyone here have a compiled list of any sort of data regarding Diablo? It does not have to be 'of interest' (which is relative from person-to-person). We've been trying to compile such a list for some time :) These notes are collaborated on at https://github.com/sanctuary/notes and are also made available through http://sanctuary.github.io/notes/ Brief status update as of 2018-02-15: * 35% of the function signatures have been documented. * 95% of the read-only global variables have been documented. * 98% of the read-write global variables have been documented. * 91% of the uninitialized global variables have been documented. Type definitions of structures and enumerates have also been documented. Quote:If you are very familiar with reverse engineering Diablo: I'd love to pick your brain on a few topics of how Diablo was written. Any particular topics you have in mind? Would be happy to try to figure it out together :) Cheerful regards, The members of sanctuary
02-15-2018, 01:33 PM
(01-30-2018, 12:23 AM)TheKillerVortex Wrote: Here's an explicit question: They are indeed hard-coded values. The actual entrance is added in trigs_init_warps_town: Code: warps[0].entrance_x = 25; // ref: 0x4619C1 and for the description text on mouse hover, the mouse X-Y map coordinates are set in trigs_set_stairway_text_town. Code: strcpy(description_line, "Down to dungeon"); Also, take a look at the global variable warps and the Warp struct. (01-30-2018, 02:10 AM)TheKillerVortex Wrote: Yes. That address points to the item type of an equipped item on the player. The Player struct is not currently documented, as it's huge. However, some fields are known. For instance, the equipped items. Code: typedef struct { The player global variable has been documented (but is currently commented out, until the Player struct is defined), and it is located at address 0x686448. Since it is commented out, it does not appear at http://sanctuary.github.io/notes/#variable/players yet. Code: // address: 0x686448 And the Item struct has been documented, thus its size (0x170) is known and the offset to its member. From this information, we can calculate what the address 0x686D8C corresponds to. Code: 0x686D8C - 0x686448 = 0x944 // offset into the player struct. Looking at http://sanctuary.github.io/notes/#struct/Item we can locate the member at offset 0x8, which corresponds to the item type. Code: typedef struct { Lastly, the item_type enum is defined at http://sanctuary.github.io/notes/#enum/item_type Code: // Item types. I hope this may provide useful for your future reversing adventures :) As you will notice, there is still a lot left to be documented in the game. Care to join us at sanctuary? :) Cheers!
02-16-2018, 12:40 PM
(This post was last modified: 02-16-2018, 12:42 PM by GalaXyHaXz.)
I was messing around with the pre-release demo and found some leftover debug/cheat code. Interesting stuff, since some of it appeared in Mock-up shots from 1995-1996. I sent this info to Mystery over at Diablo-Evolution so hopefully it can be more documented. Below is the info to recreate it yourself. I wonder how much of this could still remain in the final game, but not activated? Hex edits to Diablo.exe, each value is a 32-bit BOOL (1 for TRUE 0 for FALSE) Code: 0xBA958 Debug mode on/off Code: [CHEAT] 'P': You can hold 'P' while paused to keep moving and be invincible Also, here's what I have so far for the PlayerStruct (info taken from PS1 debug version). It's not fully finished yet, 0x54D8 bytes in size. Code: struct PlayerStruct
03-17-2018, 04:22 PM
Life/mana are stored with 6 hidden bits of precision as a 32-bit little endian number. Monster HP is also stored this way. To convert real data into displayed data, divide by 0n64 (or 0x40). Conversely, to convert displayed data into in-memory data, multiply by 0n64.
Items morph because they are stored on disk (and sent over the network) as the minimum data required to rerun the code that generated the item when it was first dropped. Items are regenerated from that data on receipt over the network or from disk. If you change a derived field, it reverts when the item is regenerated. If you change the data tables (such as modifying qlevels), then subsequent regeneration derives different results, hence the items morph. If you have other specific questions, post them separate from your speculation and results. I may be able to address them. |
« Next Oldest | Next Newest »
|