This is so annoying, even vulkan swap chain doesn't mention how to setup vertical synchronization:

https://vulkan-tutorial.com/Drawing_a_triangle/Presentation/Swap_chain

Bye,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Checking for "retrace" was just a few assembler instructions in ms-dos/vga graphics cards, why is this so hard now in opengl and vulkan and modern graphics cards ?!?!?

Bye,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

One of the examples I saw did turn of swap_interval to 0 but still used glutSwapBuffers.

I am not sure why it would turn it off, maybe to prevent double waiting or some bug ?

Anyway documentation for glut seems to indicates it indeed flips the buffer when retrace happens:

Slightly annoyed now that yet another library is needed to implement. I think glut is not present by default on systems, it's not default present on windows and might not be installed by graphics driver, so this would be a glut dll that I might need to
supply with my app to make it run, the example didn't come with glut so assumed it was already installed, this might be wrong, I can remember apps not working cause glut was not present, maybe windows 95 or so but still, currently on windows 7.

This was kinda the nice thing about opengl, just one dll, always there on all windows versions, but not so with glut. Maybe if I can find glut source code, might be able to duplicate it's functionality, doubt it though, probably something special ;)


"
4.6 glutSwapBuffers

glutSwapBuffers swaps the buffers of the current window if double buffered.

Usage

void glutSwapBuffers(void);

Description

Performs a buffer swap on the layer in use for the current window. Specifically, glutSwapBuffers promotes the contents of the back buffer of the layer in use of the current window to become the contents of the front buffer. The contents of the back
buffer then become undefined. The update typically takes place during the vertical retrace of the monitor, rather than immediately after glutSwapBuffers is called.

An implicit glFlush is done by glutSwapBuffers before it returns. Subsequent OpenGL commands can be issued immediately after calling glutSwapBuffers, but are not executed until the buffer exchange is completed.

If the layer in use is not double buffered, glutSwapBuffers has no effect.
"

Bye,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

FBO examples on the web seem to use glutSwapBuffers instead of SwapBuffers, not sure why, also their examples are so simple it's hard to tell if glutSwapBuffers implement VSYNC or not. Examples run so fast it's likely little to no screen tearing will be
visible without additional CPU processing to through off the timing...

Bye,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This guy seems to have discovered that rebinding to default frame buffer, might make swap interval work again, at least this may prevent the usage of glut which is at least something.

I dislike very much how opengl does not document how certain things affect other certain things.

Better to duplicate all kinds of settings in object orientated design, then to leave all these assumptions hanging in the air.

"
muhkuh
Member
Aug 2010

Hi,

I have some code that does this:

render to a FBO
blit the result to the back buffer
swap buffers

This basically works but controlling VSYNC from code by wlgSwapInterval/glxSwapIntervalSGI doesn’t work anymore as it did before when rendering was done directly to the back buffer.

Forcing vsync on/off in the driver control panel still works though. The hardware is nvidia in all cases.

Is there something about FBOs and blitting between them that could cause this? It seems like a driver bug to me but I want to be sure I’m not making a silly mistake myself. Any ideas?

Thanks

Edit:
It seems like the driver doesn’t like it when I leave the FBO active all the time. When I switch back to the default FBO before swapping buffers SwapInterval seems to be effective again. Is this expected behaviour?
"

Bye,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This blit example seems to work, there are some caveats maybe, some depth buffer might also have to be attached and such for 3D work, not sure for 2D work ;)


Here is alternative example which does not require textures:

// copy framebuffer
if(fboUsed)
{
glBindFramebuffer(GL_READ_FRAMEBUFFER, fboId);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glBlitFramebuffer(0, 0, TEXTURE_WIDTH, TEXTURE_HEIGHT,
0, 0, screenWidth, screenHeight,
GL_COLOR_BUFFER_BIT,
GL_LINEAR);
glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);
}

Replace variables in blit with your own.

Apperently frame buffer 0 is front buffer.
fboId is your frame buffer number.

Why such a simple thing is not explained anywhere in opengl documentation is beyond me.

Bye,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This guy describes glutSwapBuffers, might have lag issues.

Maybe swap interval does not have lag issues, so far on my GT 1030 did not notice any lag issues in Quake 3 Arena or so which also has this swap interval implementation, not sure if it uses glut too though.

So far without fbo speed can be 800 to 1200 fps for just clearing screen.

Will now attempt to try and mix my OpenGLControl gui code/component with framebuffers objects to see if it can be done somehow ;)

Otherwise might have to change code, don't have too, but it would be cool to have.

I just hate textures =D

Bye,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)