Emulator

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.

Oh, and just for future reference, address 0x802fd128 is money in the Japanese version of the game.