next »

[rogerlevy]

I use SDL/OpenGL.  I was wondering if anyone else is concerned as much as me with the problem of input latency on Windows.  It's acceptable with the keyboard, barely noticable.  But if I drag something with the mouse for instance, the object lags by at least 3 60fps  frames.  It makes my program look, well, retarded!  Joystick seems to be even worse, maybe 4 or 5 frames.  I have to use a keyboard-emulation program (joy2key) to get around it. 

Is there a library or some driver or a Windows API incantation that I can "plug in" to my game's window to get better latency???  I've read that DirectX is better but because I use Forth I can't use it... 

[hexageek]

I highly doubt it's got something to do with input latency. It looks like a FPS problem to me. Did you implement a FPS manager yet?

[rogerlevy]

Thank you, but, I honestly don't think it can be an issue with FPS.  There are only ~10 2D objects in the test program.  I process the entire SDL event queue every frame, and it is running at 60fps at the moment.

EDIT: btw no I haven't created an FPS manager yet!  The games I want to make at the moment are too simple to need it...

[hexageek]

When you drag something, is the SDL cursor still visible? if so, does it lag too? or is it just the object thats lagging? From your first statemnt I thought only the object is lagging that's why I think it's not a latency problem. If it was, SDL cursor would lag too.

PS: When I don't have a FPS manager (even a simple delay would work), my SDL applications always work on 100% CPU and this causes instability from time to time.

[rogerlevy]

The cursor is the Windows cursor. I haven't enabled the SDL cursor.  Objects lag the same whether in windowed or fullscreen mode.

PS: When I don't have a FPS manager (even a simple delay would work), my SDL applications always work on 100% CPU and this causes instability from time to time.

Oh, when you said FPS Manager I thought like something to deal with compensating for frames that take too long... actually I do have a simple mechanism that tries to release the CPU for a few ms if the frame was completed quickly enough.

[hexageek]

The cursor is the Windows cursor. I haven't enabled the SDL cursor.  Objects lag the same whether in windowed or fullscreen mode.

Windows cursor? I don't think you can use it with SDL window. I'm talking about the black SDL cursor. Can you enable it with SDL_ShowCursor(SDL_ENABLE) and see if it lags too while dragging objects in your game?

[Ivan]

Are you using glFlush() or glFinish() at the end of your frame rendering by any chance?

[rogerlevy]

Are you using glFlush() or glFinish() at the end of your frame rendering by any chance?

no... i don't think so... why?  would either of those be good or bad?

[Ivan]

im actually not sure about glFinish, but i had some issues with using glFlush on certain systems. I don't use it at all now, but I had similar problems when I did. Just checking.

[rogerlevy]

The cursor is the Windows cursor. I haven't enabled the SDL cursor.  Objects lag the same whether in windowed or fullscreen mode.

Windows cursor? I don't think you can use it with SDL window. I'm talking about the black SDL cursor. Can you enable it with SDL_ShowCursor(SDL_ENABLE) and see if it lags too while dragging objects in your game?

You know what, I'll double check this when I get home. I'm actually not sure now what I've done regarding the cursor ... tbc

[raigan]

I've noticed something similar on my new laptop -- windowed games often have HUGE input lag when dragging with the mouse.. like almost a second or more.

So far I haven't been able to figure out what the problem could be -- a quick test I did reproduced the lag in an OpenGL window if vsync was on, with vsync off it went away, but I have no idea why/how.

Possibly the event buffer isn't getting fully cleared each frame, so mouse input is getting to you late?

[rogerlevy]

Ok, I hadn't explicitly enabled the cursor, but it was already on by default.  I hadn't even noticed that the cursor changed color, ha.  Hey, so, it is not lagging with everything else.  I mean, that's how i noticed it - sprites would "chase" after it instead of being directly under as I dragged with the mouse button.  So, what's the prescription??

WOO-WOO-WOO-WOO!! Big Siren Update:

Added glFinish just before swapping the framebuffer.  This gave a noticeable improvement.  Now latency for the mouse appears to be 1 or 2 frames.  Which is acceptable to me.  Barely.  -The Prince and the Pea

Hmmm... it'd be interesting to find out if glFinish() improved game responsiveness for anyone else's games....

[Ivan]

it's most likely to do with vsync or something like that. make sure you have vsync disabled in SDL and try it.

   SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);

[rogerlevy]

it's most likely to do with vsync or something like that. make sure you have vsync disabled in SDL and try it.

   SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);

Disable vsync???!!!

I mean, tearing is fine ... if you like that sort of thing ...   

But seriously, I do like my vsync and would never ever disable it....

I got some success, see my editted post just above...

[raigan]

I seem to recall reading something which warned that using glFlush() or glFinish() would result in a noticeable degradation of performance. Aha, here: http://www.opengl.org/wiki/index.php/Common_Mistakes#glFinish_and_glFlush

"A modern OpenGL program should NEVER use glFlush or/and glFinish."

Is that just bs?

[rogerlevy]

"A modern OpenGL program should NEVER use glFlush or/and glFinish."

Is that just bs?

People should try them and find out!  If glFinish() turns out to be the opposite of what that article said, and, across the board, that would make me very happy... mostly because it would mean that my game would run great on most PC's... heh

[Ivan]

I had issues with using glFlush/glFinish (don't remember which now) with different systems getting weird slowdown bugs and in the end I just took them out. I do not remember exactly what happened, but I guess this is just a warning against using them.

[Will Vale]

If the driver is waiting for the command buffer to get past a certain size before kicking it to the GPU, you can end up with several frames enqueued by the CPU before the GPU starts working on them. A flush at the end of the frame ought to get the GPU working straight away so what you're seeing makes sense (glFinish calls glFlush and waits for the GPU to finish working on all the commands). You'll be forcing the CPU to idle though, so you won't get great parallelism this way.

I did notice that with some video driver control panels you can set the maximum number of frames the driver is allowed to enqueue before blocking: On mine this is "Maximum pre-rendered frames".

[rogerlevy]

A flush at the end of the frame ought to get the GPU working straight away so what you're seeing makes sense (glFinish calls glFlush and waits for the GPU to finish working on all the commands). You'll be forcing the CPU to idle though, so you won't get great parallelism this way.

That's a choice I can live with. 

Let's distinguish between "flush" and "finish".  In my own tests glFlush didn't help with lag, while glFinish did.

[Snakey]

No, not really. When you consider it, a swap buffer (how ever many you may be using) should be already finished by the time you're going to swap it ... right? If it isn't, then theres no point to swap to the back buffer if it hasn't finished rendering yet. Because of the age of OpenGL, it may have been necessary back then to provide options for systems that can't / won't handle a back buffer (probably due to memory limitations). Calling glFlush() or glFinish() is pointless because you're telling OpenGL to look for a whole bunch of work when none really exist.