There seems to be noticeable “input lag” (with keyboard or gamepad) when the SDL_Renderer is used for rendering on Windows machines. I’ve only used SDL2 (not SDL3) so far and I guess it is using DirectX9 at the back. For contrast, using opengl3.3+ feels pretty responsive. So I suspect that DX9 adds few frames of lag, at least by default. I am talking about a traditional single-threaded double buffer setup, just the default way to go that doesn’t add extra latency.
So my question is, is there a way for you guys to provide a fix for that? Will at least SDL3 use DX11 at the back as it should allow you to set queued frames to 1 to minimize input latency.
SDL_RendererInfo info = {0};
SDL_GetRendererInfo(renderer, &info);
SDL_Log("%s", info.name);
mine prints INFO: direct3d. dunno how to tell the version. I don’t know the difference between Direct3D and DirectX.
post more code. how are you reading keyboard/gamepad? can you describe “frames of lag” better?
I’m still getting started with SDL2, I’m currently reading keyboard input from SDL_PollEvent, but I’ve read I should use SDL_GetKeyboardState for smoother moment, because as of now, I have to press keys for some seconds so that several SDL_KEYDOWN events are sent. same gives with OpenGL for me
It is guaranteed that SDL_PollEvent() and SDL_GetKeyboardState() is called at the beginning of each frame, and then the logic reacts to this within the same frame and thread (if variable time step loop is what you want). I am talking about the most basic and recommended setup here.
If you are sensitive to input lag, you will notice it right away. It’s a pity as the SDL_Renderer is pretty useful and powerful now with the inclusion of SDL_RenderGeometry() function. You can do pretty, visually rich, 2D games now without shaders.
So it is even more painful to witness that a much leaner framework use, like SDL2 with its Renderer, gives you more input lag than a rather convoluted engine like Unity. Unity feels pretty responsive when I set its queued frames to 1. We really don’t need triple buffering or even more for performance reasons when we use the SDL_Renderer.
So I hope one of the maintainers sees this and finds a way to reduce the latency here. It should also be a plus for the DragonRuby toolkit, as it also using the SDL_Renderer, if I read correctly. I think the problem is really the default setup of DirectX here. XNA had the same problem with latency btw. with a default recommended setup.
SDL_PollEvent() is called in a while-loop until there are no more events, of course. Just render and move a sprite with SDL_Renderer, of course with enabled V-Sync, and you will notice a few frames more (than some alternatives can provide) of input lag if you are on Windows. I know that disabling v-sync solves this issue, but that is what we usually don’t want.
If you are sensible to input lag, feel free to check it out. Just render something interactive with the SDL_Renderer, doesn’t matter if you are on a laptop or a desktop machine, as long as it is Windows. It will be a bit more sluggish compared to Unity (with queued frames set to 1) or when you do it with opengl.
How do you test your program - debug or release? And more importantly, do you test this program in exclusive fullscreen or in windowed form?
AFAIR if the window is not displayed in exclusive video mode, all input first goes to the window manager (dwm.exe) and only from there to the program window, so there is an additional lag here.
So if you care about minimal latency, always use exclusive fullscreen mode.
The majority of users on this website are game developers and enthusiasts rather than SDL Developers. We do see Slouken and Icculus from time to time, but keep in mind that most of us are here because we enjoy SDL and want to provide assistance as best we can.
There are thousands of games on Steam and itch that use SDL2 and run on Windows, but I don’t see mention of this issue beyond what you and Elefantiho are saying . Please provide some minimal reproducible code or a link to the project.
If you are certain it is an issue with SDL2, perhaps try a slightly older version of the library. If that solves the issue then that information would be helpful if reported at SDL’s github.
I do see an issue raised in November about choppy rendering where they use SDL_SetHint(SDL_HINT_RENDER_DRIVER, "direct3d"); to work around the issue, but that was specifically an SDL3 issue. Still, you might try one of the values found here.
Those thousends of SDL2 games don’t have this issue because they don’t use the SDL_Renderer;) If you know of Steam games that use the SDL_Renderer, I would like to know them.
I prefer borderless window, and that is the recommended mode for windows. It allows for bug-free alt-tabbing because there is no context-switch that can crash your program. And counter-intuively, exclusive fullscreen can have even more input lag. Windows.
I just hope icculus or slouken get aware and spend a look into it. May be they overlooked a crucial setting that can easily fix that, just like it can be fixed in Unity by setting queued frames to 1. That’s all.
Exclusive fullscreen is designed to provide maximum performance, so what you are describing sounds impossible.
I have observed many times that windowed mode (including desktop fullscreen) works slower and increases input lag, especially in the example of my game, which uses SDL2 and SDL_Renderer and requires very precise input (down to the single frame, in 60fps or 50fps). However, when I run it in exclusive fullscreen mode, performance increases and input lag decreases (especially in the lower resolution than the native one). And this is understandable, for the reasons I wrote earlier.
If you want to lower input lag on Windows, stop using windowed mode and use exclusive fullscreen mode. And if you prefer a borderless window, then expect performance to drop and input lag to increase.
“Maximum performance” does actually imply increased input lag, as it essentially means maximum throughput. You need a pipelined architecture for maximum throughput, usually with triple-buffered frames.
But regardless whether exclusive fullscreen is better or not, borderless window should be good enough. In Unity, I wouldn’t be able to tell the difference, borderless window is just very responsive there. And in your chart (which is pretty old, so there could be changes how the OS handles that now), the difference between exlusive and borderless is less than one frame, so that’s not much of a concern. I am talking about a difference 3 frames of input lag with the SDL_Renderer, so that is more substantial.
As for Time.deltaTime and fixed timestep. This has something to do with stuttering, but it actually has nothing to do with the input lag I am addressing here.
