04-07-2014, 06:30 PM
I finally got to the bottom of this - so I know why it happens, but not really how to fix it
BGDA renders everything to a 1280 x 1024 buffer located at 0xA0000 in GS memory. It then transfers that to the display buffer at address 0 for display each frame. The display buffer is 640 x 512 on the pal version.
Now, the problem it has is that a source texture has a maximum width of 1024 pixels and it has a source of 1280 ... so it uses a trick.
It sets a TEX0 at 0xA0000 and transfers a 640 x 1024 section of that to (in the pal version) a 320 x 512 area in the display buffer. This is the 'half screen' that we see. To do the right hand side of the screen, it sets TEX0 to 0xB4000 and does the same thing only shifted right by half a screen in the destination. 0xB4000 is pixel 640 of the texture at 0xA0000.
In software mode this is fine. For hardware mode though, we see the texture at 0xb4000 as a different texture rather than simply an offset into 0xA0000 ... so we get a blank texture for the right hand side and hence the bug.
For those thinking that 0xB4000 is not half a scan into 0xA0000, you need to remember that the GS memory is not liner but swizzled in square blocks of pixels.
Ian
BGDA renders everything to a 1280 x 1024 buffer located at 0xA0000 in GS memory. It then transfers that to the display buffer at address 0 for display each frame. The display buffer is 640 x 512 on the pal version.
Now, the problem it has is that a source texture has a maximum width of 1024 pixels and it has a source of 1280 ... so it uses a trick.
It sets a TEX0 at 0xA0000 and transfers a 640 x 1024 section of that to (in the pal version) a 320 x 512 area in the display buffer. This is the 'half screen' that we see. To do the right hand side of the screen, it sets TEX0 to 0xB4000 and does the same thing only shifted right by half a screen in the destination. 0xB4000 is pixel 640 of the texture at 0xA0000.
In software mode this is fine. For hardware mode though, we see the texture at 0xb4000 as a different texture rather than simply an offset into 0xA0000 ... so we get a blank texture for the right hand side and hence the bug.
For those thinking that 0xB4000 is not half a scan into 0xA0000, you need to remember that the GS memory is not liner but swizzled in square blocks of pixels.
Ian