dolphin-memory-engine
dolphin-memory-engine copied to clipboard
aldelaro5
Ram override hotfix
Here is my rough fix for my hopefully soon to be approved pull request with Dolphin Emulator (PR #8722). Accept it, or don't. I don't care. I can just put a release build on my fork and share that around. I don't like what I had to do to fix the scrollbar, tbh.
If I ever port this to Dolphin (which is why this repos is kind of dead rn as I had plans to do it, but other stuff came up), I will consider this so I'll leave this open in case, but I unfortunately can't merge it since it's been so long I reversed dolphin stuff. Feel free to distribute your fork in the mean time.
This will never be perfect because Dolphin Memory Engine cannot know the "real" MEM1 and MEM2 sizes which emulated software have access to. Dolphin Emulator always allocates physical regions with sizes that are powers of two, and that's all Dolphin Memory Engine knows about. Falsifying the "real" MEM1 and MEM2 sizes in Dolphin Memory Engine will allow the DolphinAccessor to read from and write to allocated, unused memory following the end of "real" MEM1 and MEM2. I believe this is harmless, but worth mentioning as a limitation.
If someone could test if this still works fine on Windows, that would be helpful.
If someone could test if this still works fine on Windows, that would be helpful.
Thanks. Ill be doing tests on both platforms before merging.
Did a brief test with Windows with GameCube games, can hook fine with any MEM1 change. I'll be reaching out to others for additional validations.
So I've done a bit of my own testing, and have found that MEM1 and MEM2 both being set to 64MiB in DME and Dolphin confuses WindowsDolphinProcess greatly. When attempting to hook GCN games, it will show the contents of MEM1 in both the 0x80000000 and 0x90000000 address spaces. For Wii games, MEM1 will be in the 0x90000000 address space and MEM2 will be in the 0x80000000 address space. LinuxDolphinProcess avoids this because a magic number (0x40000) is involved in the calculations done to locate MEM2 in LinuxDolphinProcess::obtainEmuRAMInformations(). I don't know what this number means.
So I've done a bit of my own testing, and have found that MEM1 and MEM2 both being set to 64MiB in DME and Dolphin confuses WindowsDolphinProcess greatly. When attempting to hook GCN games, it will show the contents of MEM1 in both the 0x80000000 and 0x90000000 address spaces. For Wii games, MEM1 will be in the 0x90000000 address space and MEM2 will be in the 0x80000000 address space. LinuxDolphinProcess avoids this because a magic number (0x40000) is involved in the calculations done to locate MEM2 in
LinuxDolphinProcess::obtainEmuRAMInformations(). I don't know what this number means.
FYI, the number with the linux thing is I think it was a piece of metadata...maybe the the page size? You'd have to check the dolphin code for it, but I could get a relatively high certainty that it was going to appear there.
Windows I have overall access to much less info to do this heuristics so it had to be a bit more creative.
We're just waiting on your PR at this point for the Qt 6 migration. Ultimately if the functionality is the same while on normal mem, and using custom mem results in broken behavior, I'm OK with that for the final Qt 5 release since that's how it is in your 0.5.0 fork anyway.