Emulator Issues #13572
open4th player's screen in Sonic Riders Zero Gravity
0%
Description
Game Name?
[Sonic Riders Zero Gravity]
Game ID? (right click the game in the game list, Properties, Info tab)
[RS9E8P]
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
[6c784b8b7684bf39fef965040a809f6d]
What's the problem? Describe what went wrong.
When there are four cameras in the game, the fourth one will flicker constantly, I have been informed by a friend this is likely due to how the game works and makes it incompatible with upscaling and performance enhancing techniques, but wanted to mention it just in case. The game will flicker black every few frames (to the point where it could be considered an epileptic issue), unless you turn off both "Store EFB Copies to Texture Only" and "Defer EFB Copies to RAM", which hurt performance, and even then, it won't be entirely right, instead of flickering black every few frames, it will flicker to not be upscaled every few frames, lowering the resolution of the fourth player's camera screen for anyone with any upscaled resolution, which many do.
What steps will reproduce the problem?
Simply open the game and play a normal free race on the first stage with 4 human players to create 4 split screens, you should notice the flickering if you have the settings mentioned above enabled, and if not then you should notice the upscale bypassing if you aren't running at native resolution, otherwise you won't have an issue.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
[Yes 2407-76]
Is the issue present in the latest release? For future reference, please also write down the version number of the latest release.
[Yes 2407]
If the issue isn't present in the latest release, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)
[First broken version number here (if applicable)]
If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
These are two screenshots on the same version of Dolphin taken right after each other to show the issue, no inputs were made
[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]
What are your PC specifications? (CPU, GPU, Operating System, more)
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz 2.80 GHz
Windows
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
[Anything else here]
Files
Updated by Yacker 4 months ago
Gecko code for fixing this: 04029664 4e800020
Just changes the opcode at 80029664 to a blr. I don't know how dolphin handles this sorta thing, but this could make for a good default patch or something; I see no functional difference in the game with this enabled, other than resolving the flashing, which makes for a rather horrible experience to see the screen rapidly flashing between native and upscaled resolutions.
Updated by Yacker 4 months ago
So, I looked more into it and it seems that what's going on here is that it's copying from EFB to RAM in this function, and this might be causing issues with Dolphin. Ultimately, this EFB Copy achieves nothing as it's only copying the part of the screen that's about to be rendered to, and the game clears the screen after every frame, so I'm not sure why it does this--but, besides the point, it dumps all 00s into the target address. So, the puzzling part is why this would affect rendering in any way?
The best conclusion I seem to be coming to is that the disabled EFB copy is upsetting Dolphin in some way that it's causing a different EFB copy to be read as modified--this is reinforced by the idea that reducing the size a bit of the EFB copy disabled by above in where it gets copied to seems to resolve the issue as well. The EFB copy seemingly being "invalidated" by this seems to be at 80AB3964 for the call to GXCopyTex. This seems strange to me, though, as this occurs after the previous EFB copy.
I wish I could be of more help, but this is about where my knowledge ends regarding Dolphin.