Display draw/vsync flickering

Started by
3 comments, last by _WeirdCat_ 9 years, 8 months ago

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.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

Advertisement
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 ;-)


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.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

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 :')

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

shame

This topic is closed to new replies.

Advertisement