Emulator Issues #13633
openPokemon Channel: Black screen when approaching Wynaut TV
0%
Description
Game Name?
[Pokemon Channel]
Game ID? (right click the game in the game list, Properties, Info tab)
[GPAP01]
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
[b570d1f6ea59c66ceaf8497871b01e88]
What's the problem? Describe what went wrong.
[When watching the Wynaut TV, everything appears normal. However if you approach the Wynaut TV by pressing B, everything on the TV is black. UI elements still appear. A unskippable story cutscene on the tv also play as a full black screen if you had the Wynaut TV as your last TV.]
What steps will reproduce the problem?
[Equip Wynaut TV.
Turn on Wynaut TV.
Press B to approach Wynaut TV.]
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
[Have not tested, 2409-41]
Is the issue present in the latest release? For future reference, please also write down the version number of the latest release.
[Yes, 2409]
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
[Fifolog and screenshots are attached.]
What are your PC specifications? (CPU, GPU, Operating System, more)
[CPU: 12th Gen Intel Core i5-12400F
GPU: NVIDIA GeForce RTX 3060 12GB VRAM
32GB DDR4 RAM
Motherboard: MAG B760 TOMAHAWK WIFI DDR4 (MS-7D96) (U3E1)
BIOS Ver. 1.70
OS: Windows 10 Home 64-bit]
Files
Updated by pokechu22 18 days ago
- Status changed from New to Accepted
Confirmed via the hardware fifoplayer that this should work. When running it in Dolphin with the hardware fifoplayer, it gives a black screen. It looks like the game is drawing a black box over the entire screen with a slightly different depth value from the video, and that clobbers everything.
It looks like disabling "fast depth calculation" fixes this issue (though my understanding is that "fast depth calculation" is generally more accurate nowadays?)
The fifolog also shows garbage with dolphin's fifoplayer unless "immediately present xfb" is enabled.
Updated by pokechu22 15 days ago
I modified the hardware fifoplayer to screenshot depth values instead of color values. This shows me that on real hardware, the depth ends up being 0xFD70D5 for the screen and 0xFD70D6 for the black border around the screen. On Dolphin, it ends up being 0xFD70D6 for both when using the software renderer or Vulkan with fast depth calculation. With fast depth calculation disabled, the screen uses 0xFD70D6 and the border uses 0xFD70D7.
The game is drawing a black border around the edges of the screen for some reason - it also draws the TV, but then decides it needs to hide it with black. This is done by first drawing the screen contents (including a modeled in bevel), and then drawing the border over it afterwards at a similar depth. But, for the Wynaut TV, they don't actually model the border; they instead just draw a rectangle over the whole screen and rely on it having a different depth. (The Sunkern TV, which is also beveled, does have a separately modeled border drawn in black that does not overlap the screen itself.)
To make things more annoying, the Wynaut TV has a slightly curved screen. But it's so slight, it seems to not actually matter. As in, the input Z values range from 0.00000034772182289089 to 0.000000435606438031755 (with X ranging from -1.00528335571289 to 1.00528335571289), but the Z row of the position matrix is 0.000000021811075612276908941567, 0.00, 0.000999999931082129478454589844, -10.00
, and the X and Z values are small enough that the end result is only the -10.0 from W, and then the Z row of the projection matrix of 0.00, 0.00, -0.00000305176740766910370439291, -0.100000314414501190185546875
results in a consistent Z value of 0.099969796836376190185546875 (according to RenderDoc's mesh viewer, at least) for all of the vertices. The W row of the projection matrix is 0.00, 0.00, -1.00, 0.00
giving a W value of 10.0 for all vertices.
The black border also is slightly askew, with varying X (-0.687009274959564208984375 and 0.687009274959564208984375) and Z (0.000000397156867393277934752405 and 0.000000386171308264238177798688) values that end up being dominated by the W term of the position matrix Z row of -3.507437895677867345511913299561E-09, 0.00, 0.000999999931082129478454589844, -10.0000457763671875
. The same projection matrix is used, resulting in a consistent Z value of 0.099969796836376190185546875 (the same as before) for all vertices, and a W value of 10.0000457763671875.
The difference between Z/W for those two values is .00000004576233179204303, which is less than 1/0x1000000 (.00000005960464477539063). So this is very precise.
I should note that Z=0.099969796836376190185546875 doesn't quite make sense as the final depth when converted to an integer or looking at depth in RenderDoc's texture viewer. Furthermore I see z=0.09996978938579559326171875
and w=10.00
in pos
and z=0.99000298976898193359375
and w=0.100000001490116119384765625
in gl_FragCoord
in the pixel shader. I don't know why RenderDoc's mesh viewer and debugger disagree on the values, but the values in the debugger seem to match the actual output better.
The more I look at this the more confused I get. I still don't entirely understand why "fast depth calculation" makes a difference here beyond forcing some depth-related math to happen in the pixel shader when it's disabled.