Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
I'm currently using SDL contrary to specification and collecting events "asynchronously" on the main thread and rendering with OpenGL (vsync) in another thread. It seems to work fine. It may be internally that SDL is still blocking input collection on vsync, but it allows me to decouple input from rendering at least code-wise. Assuming input really is asynchronous, are SDL timestamps good enough to be used in a case such as this?:
or should I be doing my own time-stamping?
My understanding is that SDL events all use SDL_GetTicks, which is millisecond accurate, and which is only calculated at the point where the event loop receives the event. Millisecond precision is probably enough for most purposes, although whether the system actually has 1 millisecond resolution, I don't know. (But I doubt it.)
'Asynchronous' is a pretty vague term but I doubt it's relevant here.
i use "asynchronous" in two senses:
1. the input thread is waiting on events (SDL_WaitEvent) instead of pumping at a fixed frequency
2. the input thread sends commands to the renderer via an asynchronous channel (since I"m using OpenGL i guess this is kind of like simulating multi-threaded rendering via command buffers)
#2. ensure that when the renderer is waiting on VSync, input processing still happens. #1. maybe isn't necessary if events received from SDL are already properly timestamped
