..:: PCSX2 Forums ::..

You must always pick up the 32bits versions.

For information, I used libjpeg 62 and portaudio 2 API. And bz2 stand for bzip2.

Zeydlitz, I need some help on gl stuff.

I did a new full screen implementation in my branch but I still have one issue. In full screen on a 16/9 screen, the gl buffer are 4/3 unfortunately the border show bad pixel data. I want a black border. It is the same behavior in the opening of the window before the boot/game start.

Is there any way to clean the screen or reset it to a black frame ? I thinks one difficulty is the window size is bigger than the gl buffer. Any idea ?

Thanks

Edit: actually there is a glClear call in RenderStartHelper function. Not sure it clears the good buffer.

Hum I have made some test. I change the glclear in RenderStartHelper to alternate between pink and green clear. One color do not cover all the screen but a smaller part.

Then I hardcode a big size to the window in GSmain. In first pass the flash zone was smaller. Then I try the max size and the issue was gone. Now I went back to normal, but ..ARGS.. the flash did not show anymore. I tryed to reboot and played an opengl game but no sign....

I suspect a bad buffer size or a bad clear somewhere.

Anyway, I found somethings strange in ZeroGS::Create function. glClear is called (line 515) but the value of the clear (glClearColor, glClearDepth) are set later (lines 570, 571). I thinks it would probably be better to move glClearColor glClearDepth before glClear. Any thought ?

Edit: The evil returns Actually glclear no impact. Big window size neither... But Anti-aliasing change seem to clean the buffer !!!

Edit2: Have got another question ? Do you plane to use the negative AA functionality in the future. Or can it be remove. For the moment it is useless and it could optimize RH, RW function to only a shift instruction. See my patch.

Just droped by to say that the new fullscreen works like a charm! Thanks for this update =)

Quote:Anyway, I found somethings strange in ZeroGS::Create function. glClear is called (line 515) but the value of the clear (glClearColor, glClearDepth) are set later (lines 570, 571). I thinks it would probably be better to move glClearColor glClearDepth before glClear. Any thought ?

You must understand, that openGL function calls does not draw anything. Draw happening only when glBegin happened and finish at glEnd, and in ZZogl those block are hidden in glDrawArrays call. If you want to change something on screen, you MUST be sure that you call Flush() with you changes.

Quote:Do you plane to use the negative AA functionality in the future. Or can it be remove.

It could be removed, this functionality does not give FPS boost.

i can't select zzogl plugin :-( there's an error "can't find log zzogl.log".
How can i try to fix?
THX

Quote:You must understand, that openGL function calls does not draw anything. Draw happening only when glBegin happened and finish at glEnd, and in ZZogl those block are hidden in glDrawArrays call. If you want to change something on screen, you MUST be sure that you call Flush() with you changes.

Hum ok. Anyway I got an idea this morning to solve my blinking issue. After the buffer swap, the back buffer is in an undefinate state. So I call glClear to restore it to a black buffer. It do the jobs but I'm not sure on the impact. In particular performance, interlace. By the way did interlace have any utilie ?

Index: pcsx2.snapshot-3753/plugins/zzogl-pg/opengl/ZZoglCRTC.cpp
===================================================================
--- pcsx2.snapshot-3753.orig/plugins/zzogl-pg/opengl/ZZoglCRTC.cpp
+++ pcsx2.snapshot-3753/plugins/zzogl-pg/opengl/ZZoglCRTC.cpp
@@ -657,6 +657,7 @@
if (glGetError() != GL_NO_ERROR) ZZLog:ebug_Log("glError before swap!");

GLWin.SwapGLBuffers();
+ glClear(GL_COLOR_BUFFER_BIT);
}

// SnapeShoot helper

(09-12-2010, 12:41 PM)gregory Wrote: [ -> ]

Quote:You must understand, that openGL function calls does not draw anything. Draw happening only when glBegin happened and finish at glEnd, and in ZZogl those block are hidden in glDrawArrays call. If you want to change something on screen, you MUST be sure that you call Flush() with you changes.

Hum ok. Anyway I got an idea this morning to solve my blinking issue. After the buffer swap, the back buffer is in an undefinate state. So I call glClear to restore it to a black buffer. It do the jobs but I'm not sure on the impact. In particular performance, interlace. By the way did interlace have any utilie ?

Index: pcsx2.snapshot-3753/plugins/zzogl-pg/opengl/ZZoglCRTC.cpp
===================================================================
--- pcsx2.snapshot-3753.orig/plugins/zzogl-pg/opengl/ZZoglCRTC.cpp
+++ pcsx2.snapshot-3753/plugins/zzogl-pg/opengl/ZZoglCRTC.cpp
@@ -657,6 +657,7 @@
if (glGetError() != GL_NO_ERROR) ZZLog:ebug_Log("glError before swap!");

GLWin.SwapGLBuffers();
+ glClear(GL_COLOR_BUFFER_BIT);
}

// SnapeShoot helper

Interesting idea. GLWin.SwapGLBuffers(); is called two different places, though. Perhaps we should do a clear inside SwapGLBuffers instead?

Ah I did not see this one. However it is never call. You comment the call of the RenderCustom function (ffx crash)

But yes, it can probaby be move into the core function. However interlace needs some testing. In RenderStartHelper, the glclear is not always call

Code extract:
// if interlace, only clear every other vsync
if (!bInterlace)
{
glClear(GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
}

Oh, right, forgot about that. Though I think it was already commented out when I added that comment. I believe I uncommented it, got the crash, then recommented it, and added the note so I wouldn't accidentally try it again. (Though, you know, I did a quick test and it didn't crash ffx. Might be worth looking into.)

And yeah, it would need some testing...