Open Flaflo opened 3 years ago
I've tried to statically and dynamically debug CT3 to find the D3D calls that load the afformentioned textures into VRAM. However D3D function are dispatched dynamically (virtually) via an offset table, so the function signature is almost invisible in the binary. Only creation of the DX9 context is dispatched statically, which doesn't help at all.
If one finds themself looking further into the machine code, here are some functions, that I recognized, they are a good starting point, but reverse engineering the image compression will probably require another angle.
All offsets are relative to the CT3 binary
Offset | Description |
---|---|
0x00416840 | load art file function. This is called with a path to a art bank (e.g. Media/bank00.art ) and 3 unknown integer parameters |
0x005186BA | function for printing debug output. The function does not actually seem to print anything, so maybe a command line switch must be given for it to work. |
0x0051DC40 | my_file_seek function. (Microsoft Reference) |
0x005170AD | opens a file, retrieves its length and reads the file into one or two buffers. Here it gets a bit confusing. Also the bu ffer is initialized with 0xbaadf00d so the allocator may be in debugging mode? |
0x00407B20 | also closely related to opening and reading the file into buffer. Both functions are equally interesting. |
Further debugging should focus on two different angles:
CreateTexture
can be dumped and inspected. Of special interest is the question, if the "compressed" data of the art files is loaded into VRAM directly, or altered beforehand. If processed directly, the parameters and specifics of all involved D3D functions must be looked at, to figure out how to correctly parse the file.global assets
and thus should be easy to locate ingame when filled with garbage
GXTX Texture in .art banks do have more than those compressions inside. To support all texture formats the rest of them have to be reverse engineered and implemented.
Suspected compression formats: