Sign in to follow this  
TheChubu

OpenGL Display draw/vsync flickering

Recommended Posts

Hi! I'm having some weird display sync/fbo clear issues right now, have a look:

 

[attachment=22997:bug-opengl.jpg]

 

As you see there is this weird band in the middle of the screen. This is actually a recreation since I can't take a picture of the bug (it doesn't shows if I make a screenshot), but it looks just like that.

 

It actually flickers when in movement, gets worse if the framerate isn't 60 fps (ie, well above 60fps gets me a blank screen, below 60fps gets flickering incrementally).

 

It seems the band follows the line of the fullscreen quad I do for the (deferred) light pass. For now I just have a geometry pass and then a fullscreen directional light pass. Nothing fancy.

 

Flickering patterns change if I set it to fullscreen or windowed, but it's always present in one way or the other.

 

My current gbuffer setup is:

 

albedo: GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE (texture)

normals: GL_RG16F, GL_RG, GL_HALF_FLOAT (texture)

view-space depth: GL_R32F, GL_RED, GL_FLOAT (texture)

depth-stencil: GL_DEPTH24_STENCIL8 (renderbuffer).

 

I draw stuff to the gbuffer, then blit the depth data to the default framebuffer, then do the light pass writing light + albedo to the default buffer (fullscreen quad in the far plane, GL_GREATER depth test, so not to lit the background) while sampling from the gbuffer.

 

Before drawing to the gbuffer I clear depth, color and stencil. Before drawing to the default buffer (light pass), I clear color only (depth is blit from gbuffer and preserved).

 

I might not be clearing the proper color attachments in the gbuffer, I'm not sure, I have to check.

 

I've tried with swapBufferInterval 1, 0 and -1. With and without LWJGL's "Display.sync" call (it basically sleeps CPU to synchronize). swapBuffers is called only once after rendering. The actual calls made are:

renderer.render(); // Draw all.
displayContext.swapBuffers(); // Swap buffers.
displayContext.sync(); // Do LWJGL's Display.sync() call if configured to do so.

I guess that's all the relevant information, if you need more just ask.

Edited by TheChubu

Share this post


Link to post
Share on other sites
No answers sorry, (besides that it sounds like single-buffered rendering??) but if you've got a camera that can record at 60Hz (or ideally 120Hz), then you can use that as a debugging and reporting/communication aide ;-)

Share this post


Link to post
Share on other sites


if you've got a camera that can record at 60Hz
I doubt I even have a camera that can record at 30Hz :D

 


besides that it sounds like single-buffered rendering
Holy cow, you might be onto something. I'll look it up.

Share this post


Link to post
Share on other sites

Yeah! Fucking found it!

 

I had this on my default framebuffer object initialization:

FrameBuffer fbo = new FrameBuffer( 0, null, new IntArrayList( 1 ) );
fbo.drawBuffers.buffer[0] = GL_FRONT_LEFT;
fbo.drawBuffers.elementsCount = 1;
fbo.drawBuffers.trimToSize();
fbo.complete = true;
DEFAULT_FRAMEBUFFER = fbo;

I was defining the default framebuffer as the GL_FRONT_LEFT buffer. Which meant that when I set it to target in my RenderPass object for the light pass, it was drawing to the front buffer! swapBuffers swapped back buffer with front buffer and BAM, bad buffer was being draw in the screen.

 

Switched to GL_BACK_LEFT and now flickering is fucking gone.... I... I'm almost crying right now :')

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this