Raphael's Fix For Issue 92: Purple Screen

[Yeshua]

Raphael on ps2dev posted this....


He says its basically a bug in the pspsdk. If you go further down he says that and how to fix it.

Regarding the look of the graphical glitch: it actually looks a lot like if the screen got rendered in 16bit mode, but displayed as 32bit (gonna try that out with a test image to verify). Hence there's also a very small possibility that it's either a bug in sceGu library or maybe even the hardware (though I'd rather not assume that).
For starters, could you try the following:
in JRenderer::StartScene() at the end, add the following line:
Code:

sceGuSendCommandi(210,BUFFER_FORMAT);



EDIT: A simple test has strengthened my assumption about the render format. I created a TGA file which was saved in 16bit (5551) at double height of the original image, filling the lower bottom with black (0).
Then i hex'ed the TGA file, so the header said it was actually 32bit (8888) at half height. The outcome is the same as the screenshots.
http://www.fx-world.org/images/test.tga (hex'ed image)
http://www.fx-world.org/images/test_orig.tga (unhex'ed image)

In case the line from above fixes the error, we can be sure that the problem is that the hardwares "render buffer format" (PSM) register is at some place overwritten with a value other than 3 (NOT the buffer format variable in the sceGu context, since that one is used every frame to set the display format through sceDisplaySetFrameBuf and obviously sets 32bit correctly).

How do we know that this is the fix and not one of Grandmas Recipies?

Well, grandma left town and her phone has been unplugged for weeks, but thats beside the point... The reason I believe the fix is adding that line is that...
In normal wagic (without the fix) If you reset the gu enough you can get purple, with this fix you cannot get purple, no matter how many times you try you can't get purple. I mean try normal wagic.... Hold down the GU reset button for a few second, youll get purple more than once. Try it with the change, you won't get purple even if you hold it down for eternity...

[Yeshua]

He later said this...

Well, then I guess the only question left is: when and what causes this hardware register to be overwritten?...
At least it might be worth-while putting that "fix" into pspgu directly, since it's no problem to reset that register on each sceGuStart() and I'm also not sure it's just wrong coding in JGE.

This is significant

I noticed, since sceGuDrawBufferList changes the psm hardware register, but is supposed to be non-permanent (ie changed back to value given with sceGuDrawBuffer when a new display list is started with sceGuStart) it makes absolute sense to add that command in sceGuStart, since it already resets the draw buffer pointer as it's supposed to, just not the pixel format.

Hmm... need to dig out my SVN login and put a patch in
EDIT: Submitted revision 2489, fixing this bug in sceGuStart

http://svn.ps2dev.org/listing.php?repna ... rev=0&sc=1

[Yeshua]

Still don't believe me? Ok... Fair enough... Try this on for size then.... Instead of adding sceGuSendCommandi(210,BUFFER_FORMAT); to the end of BeginScene() add sceGuSendCommandi(210,GU_PSM_DXT1); and you will always get purple now. Without flicker...

[Jean]

Still don't believe me? Ok... Fair enough... Try this on for size then.... Instead of adding sceGuSendCommandi(210,BUFFER_FORMAT); to the end of BeginScene() add sceGuSendCommandi(210,GU_PSM_DXT1); and you will always get purple now. Without flicker...

That's nice and all, but you are basically forcing an open door. I mean, it's obvious the problem is, something somewhere thinks the display format is 16 bit, and something else thinks it's 32, when everyone should agree on 32. Investigation revealed the render loop is the one who thinks the display is 16 bits. When you do that, you actually instruct it to think it's 16 bits without changing the blitting part : of course you are getting the violet screen. There is nothing new there. There are a handful of ways of getting the same result, but none of them gives us a fix.

Anyway, putting that command at the start of the render loop is something I really did not want to do, for two reasons :
1. We have no idea in the world of the performance impact of this. For all we know, it may reset the whole rendering hardware and take up one second each time. "Raphael"'s comment seems to say it's cool to do it each frame, so it would mean it's technically okay : this is new information.
2. This does not fix a bug in JGE. If this actually fixes the problem, then it means the bug is either in the GU lib or in the hardware, both of which I'd rather not think. JGE initializes this once at the start of the program, and it makes sense - while it doesn't really seem to make sense to have to reset it each time, unless there is a bug in the underlying layers. So at most, even if it works - which I still have my doubts about - it's not a fix but a workaround, and a pretty ugly one at that.

[Yeshua]

Raphael said a better fix would be to put it in the GU library. If you wanna do that, this is fine. I don't think it causes slowdowns as I have it on good authority the command writes to a psm register. Raphael actually submitted the change to his sdk svn. If you have a better idea and would like to investigate further, be my guest. I am done with this issue as I have found myself a workaround that I find works for me, atleast. I thought it only be right to share this information with everyone.

If nothing else, its better having a GU reset button feature where the user has to reset the GU himself/herself...

[wololo]

Jean, please be sure to read Raphael's explanation rather than Yeshua's one.

From my understanding, there *could* be a bug in the Gu Initialization process, as in some rare cases a hardware register is not correctly initialized.
There is still a strong probability that this register is not correctly set and/or overwritten with crepes because of a bug in JGE. That being said, it seems good to add the extra security in the SDK.

[Raphael]

Anyway, putting that command at the start of the render loop is something I really did not want to do, for two reasons :
1. We have no idea in the world of the performance impact of this. For all we know, it may reset the whole rendering hardware and take up one second each time. "Raphael"'s comment seems to say it's cool to do it each frame, so it would mean it's technically okay : this is new information.

I can assure you that there is no ever noticeable nor measureable performance impact. All this command does, is write a 32bit word to the current display list, which the GU will fetch and interpret as "write value x into register y" as soon as it gets there.

2. This does not fix a bug in JGE. If this actually fixes the problem, then it means the bug is either in the GU lib or in the hardware, both of which I'd rather not think. JGE initializes this once at the start of the program, and it makes sense - while it doesn't really seem to make sense to have to reset it each time, unless there is a bug in the underlying layers. So at most, even if it works - which I still have my doubts about - it's not a fix but a workaround, and a pretty ugly one at that.

I'm completely on your side with this point. I still cannot surely say whether the behaviour in this case is a bug on WTH/JGE's side or a hardware glitch that only got noticed this way (well, at least I've heard of other projects that had the same issue at least for a short time, iirc even one of my projects once had that screen glitch for a few builds). It may be the one or the other, but what I can say for sure, is that sceGuStart did not behave "perfectly".
The problem with it is - or to be more exactly, was - that sceGuDrawBufferList is supposed to set a new render pixelformat for the duration of the current display list (for render to texture effects), but the original render pixelformat was never set back to what was setup with sceGuDrawBuffer unless another sceGuDrawBufferList was called with the initial pixelformat. Hence it was possible to create the exact same purple screen glitch accidentally by using total legal code (which maybe just never occured because sceGuDrawBufferList is rarely used at all, and if so the pixelformat most of the time is set back with sceGuDrawBufferList because you want to render something else to the screen afterwards). Fortunately, this "fix" also directly induces the "workaround" for the problem in wagic/JGE, though it doesn't reproduce that specific usecase.

I'd also rather say it's a software than a hardware bug, as it's less likely that a gu bug went by unnoticed for so long, since gu is the second most used chip on the psp.
However, there were other bugs in PSP hardware that were long unnoticed (VFPU ulv.q bug on 1K PSPs for example), so it's still possible.