Emulator Issues #12629
closed
Graphical glitch in Pokemon Battle Revolution: some of the move distortion effects look wrong
0%
Description
Game Name?
Pokemon Battle Revolution
Game ID? (right click the game in the game list, Properties, Info tab)
RPBE01 (0001000052504245)
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
b1ec7433582cc6986e11d144d968f118
What's the problem? Describe what went wrong.
On top of the shift reported in #11875 (which is triggered not only by move-related stuff like Flamethrower, but also certain other effects, like the heat distortion CONSTANTLY used in Magma Colosseum), certain distortion effects seem to not render properly, leaving this black space.
Look at attached images for examples.
What steps will reproduce the problem?
Using specific moves, such as Water Pulse, Psycho Cut, Flamethrower, or Aura Sphere.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Tested in 14914.
Is the issue present in the latest stable version?
Yes, it is present in 5.0.
If the issue isn't present in the latest stable version, 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.)
N/A
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
Attached a fifolog of Psycho Cut; if you need a better one I can try.
Not my footage, but I did find some of the problematic moves on console - https://www.youtube.com/watch?v=94iOFmSfwvE&t=68 (1:09 and 1:28 in the video)
What are your PC specifications? (CPU, GPU, Operating System, more)
Windows 7, NVIDIA GeForce GT 610, Intel Pentium CPU G2030.
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
Again, attached screenshots of some examples.
Files
Updated by pokechu22 over 2 years ago
- Related to Emulator Issues #11875: Graphical glitch in Pokemon Battle Revolution: image slightly shifted to the top left added
Updated by pokechu22 over 2 years ago
With https://github.com/dolphin-emu/dolphin/pull/10279 the shift is significantly less, and the amount of blackness in the move is also significantly less, but it doesn't go away completely. (There's still 1 pixel of blackness on the bottom/left of the screen, and it seems like that gets picked up by the moves still.)
I'm not 100% sure this doesn't happen on console. I think this video is from real hardware, and you can see a bit of black on the right side of the screen.
I'll try and record some of my own footage (with my rather crappy capture device) to see if I can reproduce it on real hardware.
Updated by pokechu22 over 2 years ago
- File BattleRevolutionRain.7z BattleRevolutionRain.7z added
- Status changed from New to Working as intended
Confirmed, this is an issue on real hardware: see this video - be warned that this video may be somewhat loud. Rain dance in particular is good for testing (6:44 for instance).
The blackness is indeed coming from 1 row/column of black pixels at the right/bottom of the screen (though, the shift issue adds a lot more blackness, making things worse). That blackness comes from the use of a scissor rectangle with a top of 342, a left of 342, a right of 820, and a bottom of 980, giving a 639 by 479 region (because the range is inclusive; ignore the offset of 342). It then makes 640 by 480 EFB copy, which ends up including the blackness. The developers clamp the texture when it's used later on, meaning anything that goes beyond the bounds on the right/bottom sticks with that last row/column (resulting in blackness); if they had used a correct scissor size, it would instead result in the last row/column of the texture which looks better.
The software renderer isn't affected, because it doesn't experience the shift, but also because it handles the scissor rectangle incorrectly (applying it to 2x2 blocks of pixels, when it actually applies to individual pixels). My scissor pull request fixes this, meaning that the software renderer will also experience the blackness.
I'm resolving this as intended as this behavior is correct to hardware (once the shift is fixed), but I'm also looking into a way to patch the game so that it uses the right scissor size and this doesn't happen.
Updated by pokechu22 over 2 years ago
The following patch fixes the black border (add it to the per-game user config):
[OnFrame_Enabled]
$Scissor
[OnFrame]
$Scissor
0x80244A94:dword:0x39080000
0x80244A9C:dword:0x38030000
I'll do a more detailed writeup of it later, but the gist of why it works is that the game is subtracting 1 from the maximum width when it shouldn't. This changes it from subtracting 1 to adding 0.
Here's a video of it on actual hardware; you can see that the black is gone.
This patch still works without fixing the shift issue. However, it causes the shifted area to be the same pixel stretched horizontally/vertically, instead of black; this is less obviously wrong, but it's still not correct. When the shift issue is fixed, this will no longer be a problem.
Updated by pokechu22 over 2 years ago
The patch is included in PR 10279. See this writeup.
Updated by intruso over 2 years ago
pokechu22 wrote:
The patch is included in PR 10279. See this writeup.
That patch is only for the NTSC/US region, isn't it?
Will it be ported to other regions?
Updated by pokechu22 over 2 years ago
I only own the NTSC-US version and thus am not able to create a patch for other versions (I don't plan on importing the other versions of the game just for this, especially since there are apparently 3 different Japanese revisions). The writeup does include an outline of the steps needed to port the patch but it's still a rather technical set of steps.
Updated by AdmiralCurtiss over 2 years ago
PAL should be:
0x8023ff50:dword:0x39080000
0x8023ff58:dword:0x38030000
Updated by AdmiralCurtiss over 2 years ago
JP Rev 1 should be:
0x80234580:dword:0x39080000
0x80234588:dword:0x38030000