 |
forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
 Posted: Sun Dec 06, 2009 11:52 pm Post subject: |
 |
|
I took a look into JGE render setup and everything that happens in the hello world sample.
Some things I found:
- The initial render setup is very rudimentary, a lot of modes aren't set explicitly. These include:
* GU_CULL_FACE and GU_CLIP_PLANES not disabled in 2D mode (but enabled, which is default anyway, in 3D mode)
* GU_COLOR_TEST, GU_ALPHA_TEST and GU_LIGHTING not disabled (though iirc they are disabled by default, still better to make it explicit)
* Most importantly: No depth buffer allocated, but GU_DEPTH_TEST not disabled and, what less people seem to know, depth writes (sceGuDepthMask(GU_TRUE)) not disabled! (On a side-note: sceGuDrawBuffer ALWAYS sets the depthbuffer to be drawbuffer+512*height*4 if it was not set before, which in the case of JGE will end up at the display buffer)
- JGfx.cpp includes both <vram.h> and <valloc.h>, which is wrong, since those are two alternative libraries to use (vram is faster, with more allocation size overhead, valloc is slower with as little as needed allocation overhead). Possibly both libraries are also linked in, so that should be changed too.
- JRenderer::Destroy() is not a safe destruction of all objects involved (see below)
Though those don't quite explain the double-pink-screen, those are points that should be fixed.
Regarding the new test method, which basically creates a new JRenderer every time SQUARE is pressed - the error is obviously, because the JRenderer::Destroy() function doesn't safely clean up everything, just calls sceGuTerm(). There's no freeing of allocated VRAM buffers, no freeing of allocated texture, vertices/object RAM.
This HAS TO cause some graphical glitch at some point.
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: |
sendCommandi(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).
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
 |
yeshua
Joined: 30 Nov 2009
Posts: 20
|
| Posted: Mon Dec 07, 2009 4:38 am Post subject: |
|
|
| I have fixed the problem with simply calling destroy() and the issue is still present |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Dec 07, 2009 4:56 am Post subject: |
|
|
have you added this line:
| Code: |
sendCommandi(210,BUFFER_FORMAT);
|
to JRenderer::StartScene()?
EDIT: I see, you only changed JRenderer::Destroy() for engine->End(). This will not solve the problem of JGE not freeing up the vram allocations ANYWHERE, ie it will always cause problems unless you only destroy/end JGE once during your programs lifetime.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
| Posted: Mon Dec 07, 2009 5:04 am Post subject: |
|
|
| I have not commited the changes to the svn as of yet. |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
| Posted: Mon Dec 07, 2009 5:12 am Post subject: |
|
|
| What header file do I include to use that command you posted above. It doesn't compile by simply just adding it... |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Dec 07, 2009 5:19 am Post subject: |
|
|
| yeshua wrote: | | What header file do I include to use that command you posted above. It doesn't compile by simply just adding it... |
It's in pspgu.h... oh wait, it's actually called sceGuSendCommandi. My fault :)
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
| Posted: Mon Dec 07, 2009 5:26 am Post subject: |
|
|
Thanks, I believe this fixes the issue. My HelloWorld Program has the "fix" in the svn.
To anyone else with this issue: Just do what Raphael said to do...
Last edited by yeshua on Mon Dec 07, 2009 6:19 am; edited 1 time in total |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Dec 07, 2009 5:56 am Post subject: |
|
|
| yeshua wrote: | | Thanks, I believe this fixes the issue. My HelloWorld Program has the "fix" in the svn. |
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.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
| Posted: Mon Dec 07, 2009 6:01 am Post subject: |
|
|
| I'm stumped man, I'm just glad we got a work around. |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Dec 07, 2009 6:32 am Post subject: |
|
|
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
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
| Posted: Mon Dec 07, 2009 7:35 am Post subject: |
|
|
| Wow, there was an error in the sdk... |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Dec 07, 2009 8:02 am Post subject: |
|
|
Yes. It's just that the cause auf the SDK bug would be if the PSM register is overwritten actively by use of sceDrawBufferList (I don't know any other function that writes to that register...). But JGE++ didn't seem to use it anywhere, so the question remains why it happened there anyway.
I'm sill suspicous it might be a hardware glitch.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
| Posted: Mon Dec 07, 2009 8:07 am Post subject: |
|
|
| In all psps? |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
|
| Back to top |
|
|
willow :--)
Joined: 13 Jan 2007
Posts: 126
|
| Posted: Mon Dec 07, 2009 10:42 am Post subject: |
|
|
| Raphael wrote: | I took a look into JGE render setup and everything that happens in the hello world sample.
|
Thanks a lot for that!
| Quote: |
Some things I found:
- The initial render setup is very rudimentary, a lot of modes aren't set explicitly. These include:
* GU_CULL_FACE and GU_CLIP_PLANES not disabled in 2D mode (but enabled, which is default anyway, in 3D mode)
* GU_COLOR_TEST, GU_ALPHA_TEST and GU_LIGHTING not disabled (though iirc they are disabled by default, still better to make it explicit)
* Most importantly: No depth buffer allocated, but GU_DEPTH_TEST not disabled and, what less people seem to know, depth writes (sceGuDepthMask(GU_TRUE)) not disabled! (On a side-note: sceGuDrawBuffer ALWAYS sets the depthbuffer to be drawbuffer+512*height*4 if it was not set before, which in the case of JGE will end up at the display buffer)
- JGfx.cpp includes both <vram.h> and <valloc.h>, which is wrong, since those are two alternative libraries to use (vram is faster, with more allocation size overhead, valloc is slower with as little as needed allocation overhead). Possibly both libraries are also linked in, so that should be changed too.
|
Thanks. I will try to clean that up.
| Quote: |
- JRenderer::Destroy() is not a safe destruction of all objects involved (see below)
[...]
Regarding the new test method, which basically creates a new JRenderer every time SQUARE is pressed - the error is obviously, because the JRenderer::Destroy() function doesn't safely clean up everything, just calls sceGuTerm(). There's no freeing of allocated VRAM buffers, no freeing of allocated texture, vertices/object RAM.
This HAS TO cause some graphical glitch at some point.
|
Just so that we don't throw too much garbage on DR.Watson's work : JGE was never meant to be able to restart the display, and I coded this functionality very recently (2 days ago). I "did" the necessary vfree calls in Wagic's svn but I believe they haven't been correctly copied over to the "purplescreendebug" project.
Besides the frame_buffer and the disp_buffer, I believe that (please correct me if I'm wrong)
1) I shouldn't free the allocated textures (This is more or less the responsibility of the game to free its textures, rather than JGE),
2)Vertices and objects being dynamically allocated through sceGuGetMemory, I don't need to free them, especially since the "Gu Reset" call is called outside of the render process.
| Quote: |
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).
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).
|
I think if it were a bug in the hardware or in the SDK, the issue would occur much more often than that, in lots of homebrews.
I've confirmed that the variables in the sceGu context do not get overwritten... is there any way that we overwrite a hardware register through a bug in the application ?
| Quote: |
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.
|
When you say "changed back to value given with sceGuDrawBuffer when a new display list is started with sceGuStart", do you mean that it's what the SDK should be doing but it doesn't (the bug you fixed)? Or do you mean that it's what already happens(In which case, since JGE correctly calls sceGuDrawBuffer there shouldn't be any issue?)
_________________
Wagic. Play that card game against an AI on your PSP |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Dec 07, 2009 9:25 pm Post subject: |
|
|
| Quote: |
| Quote: |
- JRenderer::Destroy() is not a safe destruction of all objects involved (see below)
[...]
Regarding the new test method, which basically creates a new JRenderer every time SQUARE is pressed - the error is obviously, because the JRenderer::Destroy() function doesn't safely clean up everything, just calls sceGuTerm(). There's no freeing of allocated VRAM buffers, no freeing of allocated texture, vertices/object RAM.
This HAS TO cause some graphical glitch at some point.
|
Just so that we don't throw too much garbage on DR.Watson's work : JGE was never meant to be able to restart the display, and I coded this functionality very recently (2 days ago). I "did" the necessary vfree calls in Wagic's svn but I believe they haven't been correctly copied over to the "purplescreendebug" project.
Besides the frame_buffer and the disp_buffer, I believe that (please correct me if I'm wrong)
1) I shouldn't free the allocated textures (This is more or less the responsibility of the game to free its textures, rather than JGE),
2)Vertices and objects being dynamically allocated through sceGuGetMemory, I don't need to free them, especially since the "Gu Reset" call is called outside of the render process.
|
I guess you are right, JGE wasn't meant to be restarted during one program cycle.
Your are also right on your two assumptions. Textures and any dynamic data should be handled by the app itself, as well as anything allocated through sceGuGetMemory not needing to get freed (most of the time the display list is declared as global array, hence is static memory which cannot be freed anyway).
| Quote: |
| Quote: |
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).
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).
|
I think if it were a bug in the hardware or in the SDK, the issue would occur much more often than that, in lots of homebrews.
I've confirmed that the variables in the sceGu context do not get overwritten... is there any way that we overwrite a hardware register through a bug in the application ?
|
That's actually what makes me wonder if it really is a hardware/SDK bug. Well, actually, there WAS a small SDK bug in fact (see next quote), however the cause of this isn't what happens in JGE/Hello World sample.
However, as it seems, this fix also completely fixes the occurance of the PSD in JGE.
| Quote: |
| Quote: |
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.
|
When you say "changed back to value given with sceGuDrawBuffer when a new display list is started with sceGuStart", do you mean that it's what the SDK should be doing but it doesn't (the bug you fixed)? Or do you mean that it's what already happens(In which case, since JGE correctly calls sceGuDrawBuffer there shouldn't be any issue?) |
I meant that is what the SDK should have been doing (and is doing now).
Basically, there are two functions that set the current render pixelformat,
sceGuDrawBuffer and sceGuDrawBufferList.
The first one is the 'static' setup you call on initialization time, which defines the default render psm. The second one is a temporary change for the lifetime of the current displaylist (like for render to texture etc.).
Up till now, a new display list was only initialized with the current drawbuffer address and size, but not the pixelformat - hence why I call it a bug.
However, since JGE nowhere uses sceGuDrawBufferList, it makes me wonder what else could change this hardware register.
Will probably need further investigation if it is of any interest.
At least I'm glad I could help you get rid of that nasty bug :)
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Mon Dec 07, 2009 9:46 pm Post subject: |
|
|
| yeshua wrote: | http://wololo.net/forum/viewtopic.php?f=15&t=906&p=8089#p8087
You may want to respond to this Raphael... |
I'll respond to this today evening, as I don't have my personal e-mail account login with me at work.
Thanks for the notification :)
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
willow :--)
Joined: 13 Jan 2007
Posts: 126
|
| Posted: Mon Dec 07, 2009 9:49 pm Post subject: |
|
|
| Raphael wrote: |
At least I'm glad I could help you get rid of that nasty bug :) |
Yes, thank you very much!
This bug has actually plagued my game (and, probably, other JGE related games) for more than one year now (I posted a screenshot of the PSD on my blog on the 15th of august 2008 !)
I confirmed adding the call at the end of "BeginScene" removes any occurrence of the issue.
Strangely, in Wagic, repeatedly restarting the GU ends up with some icons/fonts becoming garbage. These textures are stored in the VRAM, so I'm assuming my code is still doing something nasty somewhere (which could well be the root cause).
I will continue investigate and I'll update this thread if something new comes up, but I confirm that this change got rid of the Purple Screen in JGE :)
_________________
Wagic. Play that card game against an AI on your PSP |
|
| Back to top |
|
|
yeshua
Joined: 30 Nov 2009
Posts: 20
|
|
| Back to top |
|
|
willow :--)
Joined: 13 Jan 2007
Posts: 126
|
| Posted: Tue Dec 08, 2009 9:59 am Post subject: |
|
|
The PSP SDK changes very often.
What changed around that time was JGE. It went from version 0.2 to version 1.0.
That's far in my memory, and I didn't know PSP programming at all at that time, so I don't know what changed exactly.
_________________
Wagic. Play that card game against an AI on your PSP |
|
| Back to top |
|
|
Raphael
Joined: 17 Jan 2006
Posts: 646
Location: Germany
|
| Posted: Wed Dec 09, 2009 12:37 am Post subject: |
|
|
I took a quick look into the PSPSDK SVN revision log, but couldn't find anything related to that back from 2years.
Actually I'm pretty sure nothing has changed to cause that behaviour of sceGuStart/sceGuDrawBuffer(List), rather the code was like that from the beginning.
As I stated in my post on the wagic forums, it's pretty unlikely that misbehaviour of pspgu was to be found in a normal way, since whenever you use sceGuDrawBufferList for some render to texture effects you *normally* switch back to your framebuffer renderformat with sceGuDrawBufferList again to finish rendering the current frame.
I'm still guessing there's another little software bug in JGE or Wagic that has caused that bug to appear (and appear so relatively steadily and reproducible), though a hardware glitch is not completely impossible to be the root (though more unlikely).
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
