Stefanos A. wrote:
2014/1/23 slimshader <@slimshader (@slimshader)>
Stefanos A. wrote:
After trying several threading strategies, my current preference is to keep rendering and window management to the main thread, but handle input on a secondary thread. So far, this has proven the best method to maintain responsiveness without impacting compatibility.
But how that does help? If main thread is blocked, then you don’t refresh your screen to show the impact of processed events. In my experience event handling is tiny fraction of a frame. Do you mean that with 2nd thread event handling you avoid “busy” system cursor / window appearing to hang?
The point is not to improve performance but to minimize latency between the user pressing a button and the world reacting to that button press.
If you handle input in your rendering thread, then any dip in the framerate will increase input latency, which can be jarring (esp. on slower systems that cannot maintain a stable framerate.) By spawning a separate thread for input, the OS scheduler will “smoothen out” input latency even when your framerate dips below 10 fps.
Of course, this only helps if your world update rate is decoupled from your framerate. In my case, I will skip up to 12 frames in order to guarantee a pseudo-fixed update rate. In other words, I prioritize world updates (60 updates/sec no matter what) and only render frames as a best-effort.
This way, if the player presses the “fire” trigger then she will shoot the enemy immediately even if she is running at 5 fps.
If the input was handled in the same thread, then the “fire” button would take up to 200ms to register - or it would be skipped completely, if the player lifted her finger before the 200ms mark. This would place the player at a severe disadvantage (hi, Diablo 3!)
Clean now
A question: I just tried to build minimal GL ES2 app under Win but I am getting unresolved externals for glClear, glClearColor and 2 more in sdl_main function. So it clearly wants to use full GL. I assume you use SDL2 with ANGLE?