dreamsyntax
commented
2 months ago I'm aware this is an issue, that said I've never encountered it when dealing with GC titles (MEM1 only) personally, and I use DME regularly on Windows and Linux.
If you open a PR it would be greatly appreciated, other users have mentioned the same as you describe. There's also some issues with how DME hooks in general on Windows, per relevant comment: https://github.com/aldelaro5/dolphin-memory-engine/pull/47#issuecomment-1790194354
Unless I'm misunderstanding your approach would resolve any OS specific issue for detecting MEM1/MEM2/ARAM - including when using custom MEM1/MEM2 sizes.
Related: https://github.com/aldelaro5/dolphin-memory-engine/issues/68
Something I have noticed over the past 4 years or so of using Dolphin Memory Engine is that the memory detection it has is relatively unstable and likes to fail on occasion. I imagine this is due to the very arbitrary nature of Dolphin Memory Engine's memory detection implementation.
There is a straightforward fix for this. Dolphin already exposes a shared memory pool which can be accessed as if it were the memory of Dolphin Memory Engine--that is to say, you don't need to pass through the OS layer to read/write to the shared memory pool once you have attained access to it. This is a guaranteed approach to the problem that removes any arbitrary assumptions. To me it is pretty clear that this should be the approach, and there's really no reason not to switch to it.
Well, there is one reason. I'm unsure if the ARAM or MEM2 segments are shared in this way, or if it is only MEM1. Regardless in the worst case scenario, a PR for Dolphin Emulator to expose these segments of memory as well would probably be in good order.
If this isn't addressed in the nearer future I'll probably look into doing it myself and submitting such PRs.