SwapBuffers Issue

[polygone]

Hey can I get some feedback please if anybody else is experiencing this issue?
https://github.com/enigma-dev/enigma-dev/issues/165

[TheExDeus]

Yes, I have the flickering. Just like I had it before on a totally different system.

[forthevin]

I get the issue on my Windows system, but not my Linux system.

[polygone]

Interesting. It must be different in GM due to Direct X? But this was working for me before on this system, so something must have changed in ENIGMA or (I think) I may have updated a driver at some point which could have possibly affected it. But the fact that it doesn't seem to be working for anybody on Windows now suggests to me that something in ENIGMA has changed, but I have no idea what that could be?

This is what ENIGMA is using to set-up the drawing in WINDOWSstd.cpp:

Code: [Select]

void EnableDrawing (HGLRC *hRC)
{
    PIXELFORMATDESCRIPTOR pfd;
    int iFormat;

    enigma::window_hDC = GetDC (hWnd);
    ZeroMemory (&pfd, sizeof (pfd));
    pfd.nSize = sizeof (pfd);
    pfd.nVersion = 1;
    pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
    pfd.iPixelType = PFD_TYPE_RGBA;
    pfd.cColorBits = 24;
    pfd.cDepthBits = 16;
    pfd.iLayerType = PFD_MAIN_PLANE;
    iFormat = ChoosePixelFormat (enigma::window_hDC, &pfd);

    if (iFormat==0) { show_error("Total failure. Abort.",1); }

    SetPixelFormat (enigma::window_hDC, iFormat, &pfd);
    *hRC = wglCreateContext( enigma::window_hDC );
    wglMakeCurrent( enigma::window_hDC, *hRC );
}
Then SwapBuffers(enigma::window_hDC); for screen_refresh(). Looking through git though, none of this has changed in 3 years which is before I originally posted the raytracing example.

[TheExDeus]

I think something changed for you, not for ENIGMA. Because for me this has always been the case. Maybe others on win systems as well. You were one of the few who hadn't have the problem.

[polygone]

hmm I'm not sure.

Anyway this is the same problem that is cause draw_getpixel() to not work after screen_refresh() which is an incompatibility with GM. Also if you turn off background drawing in the room editor now, so the screen isn't cleared to a colour then this buffer swapping will also be seen.

You can test in this file:
https://www.box.com/s/p8w6bs1c0vf1gdj3ex9g

Press Right/Down to move the block on key press. E/S to move the block on key hold. At 30 fps pressing Right/Down to move the block doesn't cause the flickering to happen (because then it's getting drawn on both buffers, unless you press it super fast - you can get it to happen at lower frame rates) but if you use E/S to move on hold instead you will get the flickering.

So the solution to this problem is: Repeat all the drawing after a screen refresh so it's on both buffers. Or just don't call screen_refresh more than once
But I do also want to know why it's different in GM.

[TheExDeus]

Well it is buggy because in double buffering the first image should be show on the screen, while the second is rendering, and then the second is flipped with the first one. So the first one holds the previous image all the time. Here though, they seem totally different. Like one part is drawn on one buffer and the other part is draw on the other. That is not how double buffering should work. So I think the problem could be elsewhere. Unless you can disable double buffering and test then.

[polygone]

I've just realized there are going to be scenarios where a single screen_refresh() doesn't work properly. As per this file:
https://www.box.com/s/2oheia1qs3u9n14i5p7c

Hold space to test, and you will see that the wrong drawn text is shown (because it's showing the text from the previous buffer). If you uncomment the other screen_refresh then it will display the correct text. The fact that it works at all to draw on the screen is kind of a hack that relies on the likelihood that the previous frame is the same.

EDIT: I've just thought of adding a moving object to it. When you do that you can see more easily that it jumps back when you hold space. So this is going to look nasty for people on Windows that use screen_refresh for a pause screen (which is common) because it's going to skip the frame back when they pause and it will be noticeable.

[TheExDeus]

Yes I can confirm the problem in your second test as well. But I still seems very wrong for me. That is not how double buffering works. There should not be two different frames, as you can only see the one that has finished rendering and the other which is still rendering. Here we see two completely rendered frames, but with differences because it just renders on one buffer, then flips and renders on the other. In the end we have two buffers with alternating frames. Maybe I am just than idiot and this is how double buffering works, but then everyone should have this problem.

Poly have you tried disabling double buffering and testing? Maybe enable triple buffering?

[Goombert]

Yah ExDeus is right, the whole point of double buffering is to get rid of flickering, you continue to draw what was last drawn while drawing the new stuff then swap at the end of draw events.

[polygone]

I'm not sure how to swap to triple buffering? Wouldn't you need a fbo? I read this:
http://www.opengl.org/wiki/Swap_Interval

In any case I don't think triple buffering would resolve it. Since it will be swapping the buffers the same.

As for single buffering, yes that's going to work but it looks terrible as the drawing is done automatically.

I'm not sure if the double buffering is set-up correctly or not, and if not how to make it correct. I read something about WGL_DOUBLE_BUFFER_ARB not sure if we should be using that or how to use it?

EDIT: This source here: https://github.com/vanfanel/SDL12-kms-dispmanx/blob/master/src/video/wincommon/SDL_wingl.c seems to be doing shit with it for the pixel format crap.

[Goombert]

Polygonz, hey bud, no lol I do not think I don't, no I'm %99.9999 percent certain you do not need a VBO. Vertex Buffer Objects just take the vertices in a model and pack them together into an object that handles storage and sends them to the GPU for fast rendering, so I do not know what that would have to do with tripple buffering?

Also while we are on fixing the double buffering and swapping, we should also take the oppurtunity to finally add MSAA and SSAA to the loop so it can down sample and then we can have some nice Anti-aliasing.

[polygone]

fbo*

[Goombert]

Oh ok yes that would make sense, hey are you on IRC? I got Ism's network functions working and made a simple client to server example and http request ^_^

Edit:

I made it do a simple http request and query our websites code ^_^

[TheExDeus]

As for single buffering, yes that's going to work but it looks terrible as the drawing is done automatically.

"That's going work" means you haven't tried it. Because as I said, this is not how double buffering works. So either it's not double buffering problem in the first place, or we just configure double buffering wrong in the GL init.