Modifying Dolphin to redirect a pointer to custom data

[JillCrungus]

I'm currently trying to see if it's possible to create a modified version of Dolphin in order to help bolster modding for a game, namely TimeSplitters: Future Perfect.

While TSFP has a decent amount of freedom in terms of modding, some of the very important stuff is still hardcoded.

As an example, the problem I'm currently trying to solve is what the game calls character sets. All levels have specific character sets that dictate which specific characters can be used on any given level. This is unfortunate when it comes to modding because of how restrictive it is.

However, the way the game handles these is by having a structure which contains different settings for the level, one of which is a pointer to the structure containing the level's character set data.

That means that if there were a way to change this pointer to point to somewhere with our custom character set data, (which would be ideal since it means we wouldn't have to strictly stick to the same or less character count as the original), we could easily bypass the hardcoded character set issue.

Ideally, the solution would be to have Dolphin read a file which details the custom character set data and store the information in a struct that matches what the game expects. Dolphin would then look up the location that the original pointer is at for whatever level is being modified and replace it somehow with a pointer to the data that Dolphin read instead.

Is this at all possible? I know that Dolphin can patch functions, I don't know if any of the same systems can be utilised to accomplish this too. Thanks in advance for the help.

[JosJuice]

This should be possible with Gecko codes (though you might need a non-trivial amount of them). First one Gecko code to overwrite the pointer with a different pointer, then several Gecko codes to write the new struct to the location of memory that the new pointer points to. If this is too restrictive, I would suggest modding the disc image in some way.

[JillCrungus]

(02-25-2020, 09:15 AM)JosJuice Wrote: This should be possible with Gecko codes (though you might need a non-trivial amount of them). First one Gecko code to overwrite the pointer with a different pointer, then several Gecko codes to write the new struct to the location of memory that the new pointer points to. If this is too restrictive, I would suggest modding the disc image in some way.

I'm not sure that either of these solutions would work for my purposes. Codes would not work as I'd have no way to read from an external file with those.

Writing a tool to modify the executable would solve that but still leaves the issue of finding space to put the new data, figuring out a way to handle adding multiple different replacements, etc (which is also an issue with codes). and in general modifying the executable's actual file is something I'm trying to avoid.

I guess what it boils down to is needing some way to point to the structure in Dolphin's memory rather than needing to find somewhere in the game memory to put it. This means I would be able to easily write code in Dolphin to parse files detailing replacement character sets and then automatically redirect the old pointers to the new data. I don't know if it's at all possible to set it up in a way that the emulated game can access Dolphin memory though. Maybe that's the completely wrong solution too but that's the only thing I can think of.

[JosJuice]

(02-25-2020, 09:24 AM)JillCrungus Wrote: I guess what it boils down to is needing some way to point to the structure in Dolphin's memory rather than needing to find somewhere in the game memory to put it. This means I would be able to easily write code in Dolphin to parse files detailing replacement character sets and then automatically redirect the old pointers to the new data. I don't know if it's at all possible to set it up in a way that the emulated game can access Dolphin memory though. Maybe that's the completely wrong solution too but that's the only thing I can think of.

This isn't really possible. The closest thing to that would be hacking Dolphin to give the GameCube more RAM and then putting the data in that new region of RAM.

[JillCrungus]

(02-25-2020, 07:37 PM)JosJuice Wrote: This isn't really possible. The closest thing to that would be hacking Dolphin to give the GameCube more RAM and then putting the data in that new region of RAM.

Is that actually possible? That sounds like it'd be a solution that works for me since I was already expecting it to require a custom build of Dolphin.

If it's possible is there anywhere you can point me that can help me accomplish that? Dolphin's codebase is kind of intimdiating and I've so far only been playing with the HLE patching stuff.

[JosJuice]

If you want to expand the RAM size, take a look at the changed files here: https://github.com/dolphin-emu/dolphin/pull/8321

[JillCrungus]

(02-26-2020, 06:31 AM)JosJuice Wrote: If you want to expand the RAM size, take a look at the changed files here: https://github.com/dolphin-emu/dolphin/pull/8321

Thank you, I've been playing with this for a bit but I'm having some issues. With the extended RAM, OSREPORT logging does report the memory as 48MB and Dolphin itself has no problem reading and writing into the extra memory with PowerPC::HostRead and PowerPC::HostWrite, but as soon as I try getting the game itself to read it problems occur, most likely because I'm doing something wrong.

My assumption was that since MEM1_ARENA_END is usually 0x81800000, this would mean that everything after that would be part of the expanded memory and free for use.

I set up my test by writing my replacement charset data (which was the same as the original with a single character ID changed) starting at that location and then changing the game's pointer to the data to point at that data instead. This caused the game to crash as soon as it tried to load the data.

I've tried playing around with where I'm starting the data, increasing the number to be much further away from what I previously tried (e.g In one run I used 0x81C5F650, which is the original offset of the data + 0x1800000 which is the original RAM size) but I've had no luck and the game always either crashes or acts as if it's reading nothing but 0s. Is there something else I need to change to allow the actual game to read from the extra memory, am I working with completely the wrong locations or do I need to do something to the address before replacing the pointer? Maybe something else?

[JosJuice]

Maybe the game is doing some kind of masking of the pointer...? If you inject some code into the game that just reads some data from the new memory region (without calling any of the existing code in the game), does that work?

[JillCrungus]

(02-27-2020, 02:34 AM)JosJuice Wrote: Maybe the game is doing some kind of masking of the pointer...? If you inject some code into the game that just reads some data from the new memory region (without calling any of the existing code in the game), does that work?

I'm not sure that game does anything like that, I've not seen anything that could indicate it when reversing it. Though, I'm not sure how to do what you suggested so I don't know if I can be completely confident.

[JillCrungus]

I've been looking into this again and I noticed something when fiddling with the memory viewer. The memory viewer doesn't recognise the addresses in the "extended memory" as being valid RAM addresses in any address space, with PowerPC::TranslateAddress returning PAGE_FAULT. The strange thing is that when I check HostIsRAMAddress during writing the data it returns true with no issues (had trouble going through it with the debugger - compiler shenanigans?) . I have no idea if this is unrelated to the crash or if it possibly hints that there needs to be more done to properly extend available memory beyond what was shown before.