It's also now possible to add configurations for new DF versions without having to recompile. This means you don't need to wait for me to release a new Dfterm2 version when next DF version comes out. I'll post a document on how to do that when I have time.
Here's a quick guide on how to add new addresses when a new DF version comes out.
The addresses are listed in dfterm2.conf (it is read as a Lua script) which is in the installation directory of Dfterm2. This file has entries in this form:
addresses = {
{ name = "DF 31.25",
size_address = 0x0073507C,
screendata_address = 0x00734D1C,
checksum = 0xFBFF0FC9,
method = "PackedVarying" }
}
Here, you could add a new DF version, let's say DF 34.2 for example.
addresses = {
{ name = "DF 31.25",
size_address = 0x0073507C,
screendata_address = 0x00734D1C,
checksum = 0xFBFF0FC9,
method = "PackedVarying" },
{ name = "DF 34.02",
size_address = 0x008100F4,
screendata_address = 0x0080FD94,
checksum = 0xD635560F,
method = "PackedVarying" }
}
You should change the name, the size address, screen data address and checksum for each new version. "PackedVarying" refers to the format in which the screendata is in the memory and it has been the same for all SDL versions since 40d times.
The addresses are relative to the base address of Dwarf Fortress.exe when it's loaded in memory. In older Windows versions that don't have
ASLR, the base address is always 0x00400000. Any self-respecting memory inspection tool can give you the base addresses for loaded modules.
In the address specified by size_address, there are two consecutive 32-bit values that tell the width and height of the DF screen. Using search features of a memory inspection tool, this address should be easy to find.
In the address specified by screendata_address, there's another address that points to the screen data. If double buffering is being used, it alternates between the buffers. You can find this address by first finding the actual screen data buffer. What I do is go to the Arena mode, search for + (the arena has a lot of smooth floor), then go to the unit or reports menu and find the letter that used to be occupied by the +.
Then, I view the memory around the address I find and check where the screen data buffer begins. Then, I use a search to find an address that points to that buffer. This should give the address what goes into the screendata_address (just remember to take relative address instead of absolute).
The screen data buffer uses 4 bytes per square. The first one is CP437 code point to the character being used and the other bytes are used for color information.
I've noticed that usually the addresses slightly increase between minor DF versions and more between major releases.
As for the checksum, you can get it by configuring Dfterm2 to load the new DF version (even though it doesn't recognize it). Dfterm2 attempts to load it, notices it doesn't recognize it, and then give you the checksum in its log.
Once you add a new entry to the dfterm2.conf, you need to restart Dfterm2 to get it load the new settings.