[0.17.63] Nearly unresponsive UI when game.speed set to extremes
Posted: Tue Aug 06, 2019 2:41 pm
When setting game.speed to extremes for a given processor, the UI becomes difficult or impossible to use. At higher speeds, it gets worse over time, as expected.
As shown in this video, it takes a little over three and a half minutes to quit the game. I used a script to use the Windows "show mouse pointer location" to coincide exactly with mouse clicks, so that you can visually see when I clicked and when the UI responded:
https://youtu.be/cnNYJmdBIv0
As I barely understand and can infer, that's because HID inputs are run inside--and at the mercy--of the same thread as the game simulation. I understand that it's probably working as the code is written to work...but is the intention of the working code for the UI to be nearly unusable and at the mercy of the game simulation?
I remember there being situations in multiplayer in which slow systems couldn't use the UI and quit the game, and that was fixed. What could be done here?
What about hard-coding 60 fps/ups to menus and pausing the simulation thread's game.speed setting? When the user pauses the simulation with ESC, should the simulation and UI both continue to run at 0.6 fps/ups or ten-million-plus fps/ups?
What about a separate, duplicate thread watching for HID input? It doesn't have to relay into the simulation thread, but if ESC or similar is detected, it pauses the simulation thread and goes into the hard-coded 60 fps/ups menu. Just trying to share ideas, not claim that I am Linus Torvalds, haha.
As shown in this video, it takes a little over three and a half minutes to quit the game. I used a script to use the Windows "show mouse pointer location" to coincide exactly with mouse clicks, so that you can visually see when I clicked and when the UI responded:
https://youtu.be/cnNYJmdBIv0
As I barely understand and can infer, that's because HID inputs are run inside--and at the mercy--of the same thread as the game simulation. I understand that it's probably working as the code is written to work...but is the intention of the working code for the UI to be nearly unusable and at the mercy of the game simulation?
I remember there being situations in multiplayer in which slow systems couldn't use the UI and quit the game, and that was fixed. What could be done here?
What about hard-coding 60 fps/ups to menus and pausing the simulation thread's game.speed setting? When the user pauses the simulation with ESC, should the simulation and UI both continue to run at 0.6 fps/ups or ten-million-plus fps/ups?
What about a separate, duplicate thread watching for HID input? It doesn't have to relay into the simulation thread, but if ESC or similar is detected, it pauses the simulation thread and goes into the hard-coded 60 fps/ups menu. Just trying to share ideas, not claim that I am Linus Torvalds, haha.
It's an edge-case scenario, I know, but is the game ready for 10 million or greater UPS for an extended period of time? If I let it run like that for 12 hours, would there be a problem?