The infamous low res gfx problem.

[Gumboots]

Yup, doesn't work. Game runs but gfx are the same. I'd say that the variables there are just being listed for reference (like for debugging messages or whatever) and that the code I'm really after is hiding elsewhere.

I have a bit of a plan, but don't know how well it will work. Take the famous "Vista fix" with engine.cfg. Most of the file is just empty. Dump looks like this.

Code: Select all

............ ........................................€?.....ÿÿÿÿ.............’.†?............................=.Eƒï.....?ÍÌÌ>...?....c...........................–...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

The parts that aren't empty probably represent the "Disable hardware T&L" setting (can't remember what else is in that section of the settings). By enabling and disabling various settings throughout the game, and checking the hex dump as you go, it may be possible to build up a useful picture of some of the general syntax.

----------------------------------------------------------------

Ok, I picked up a basic (and slightly unstable) disassembler and started playing with it. Very interesting. Turns out RRT3 was written in x86 assembly, which is what I suspected. That part in the hex file about Total SRAM: %1 Mb hides a lot more than it seems. If I run the .exe through the disassembler it wont (by default) expand every byte into the underlying code.

If I do the expansion manually for just the % sign in SRAM: %1 Mb, it brings up a lot more code in x86 assembly. Things like calling various registries, pointing to addresses, bla bla bla. It's a bit mind-boggling at the moment, but at least the code shows recognisable operations now.

Another example, the engine.cfg file with the Vista fix in it. First shot is what it looks like in a hex editor.

Second shot is what the same file looks like when run through a disassembler.

engine_cfg_disassembler.png (11.71 KiB) Viewed 2600 times

In the second shot, sbb means "integer subtraction with borrow", ax is an 8 bit registry IIRC, and [si] should be a target address. I can see learning enough of this to get decent graphics is going to be a mission. At least there's some hope of producing traceable code now.

[Sugus]

From my point of view the disassembly presented shows the contents of a (short) data section, not program code. (I was using assemblers in the 80's and I've never seen a valid sequence of assembly statements like this. )

[Gumboots]

Ok, well that's borked then. I know disassemblers have trouble reconstructing some things, especially if line numbers and variable names have been stripped.

Way I see it, there are three possible ways of tackling this issue. One is to basically try and reconstruct the parts of the source code that are relevant, then edit them to suit. That would be the most efficient code in terms of results, but is not going to be a simple task.

Second option is to go with the proxy .dll file and intercept the VRAM number there. That's starting to look like a good one.

Third option is to install and hack DirectX 8, which is what RRT3 was coded for and what it still partially relies on. These days it's an odd mix, with it calling the few DirectX 8 files that install with the game for some things, and calling the DirectX 11 64 bit files for some other things. I suspect they don't always play nicely together, and if it referenced a straight DirectX 8 32 bit installation for everything it may work better.

That would be good, because it's fine running different versions on the same box, so any newer apps could call DirectX 11 64 bit like they do already and RRT3 could call the old DirectX 8 32 bit.

I ran RT3.exe through Dependency Walker last night, and it grumbled about the mix of 64 bit and 32 bit dependencies. Obviously it's not fatal (the game still runs) but it may not be all that great either.

[Gumboots]

This can be locked now that it's no longer relevant.

[Hawk]

See this topic for the solution for this issue: viewtopic.php?f=82&t=3428
In particular this post: viewtopic.php?p=33932#p33932