With that, I'll have to stop there for now especially since I don't know which part of the system is having issues and it seems to be some broken game logic outside the rendering pipeline for now.
#Condemned 2 bloodshot ps3 cover ps3#
It is likely that rpcs3 returns addresses that are not exactly what was expected with PS3 and this fucks up the game's logic somehow. The ring buffer corrupts at specific offsets as well, which to me sounds like some broken math in the game itself.
The shader transfer is done purely in CELL code, RSX is not involved here. It can be proven that the fragment shader is the wrong one, since the previous calls use the same vertex program as the bad draws, but their fragment stage interprets the shaders completely differently (wrongly in fact). 
The game does not have any sort of feedback with RSX, it does not sample the framebuffer, nor does it use ZCULL query data. All the addresses of all shaders are 4096 bytes apart. Each 'shader' is being allocated in a ring buffer with a page alignment. The game does not have proper shader allocation. I can verify this by inspecting other changes around the binding to show it is expecting textures and also matches the shader structure (register allocations, etc) of the correct shader. The game definitely thinks the correct shader is loaded at the memory address. Of course performance is very poor using interpreters. It is however related to performance, i.e the graphics are mostly stable when using PPU interpreter (though still not perfect) and worst with PPU LLVM. This is also not a race condition - the bad shader is there even if you wait forever. I also isolated it to a situation where the right shader is used before and after the affected draw calls. 
It seems to be a valid shader just loaded to the wrong place. It is the same bad shader each time, even if you reboot the game, so this is not a case of memory being corrupt. The game has some other shader that is loaded sometimes instead of the correct one. Motion blur filter incorrectly applied to surfaces.įor the second type (the most distracting and easiest to catch with tracing tools) I found it happens because of a shader swap.
Unfortunately, RSX rendering has nothing to do with the underlying cause here. After looking at this for a while, I now understand why it is flickering.
0 kommentar(er)
