Key press/release events need to get registered at the time they occur, and handled in this order. This would allow for low FPS, but an accurate (deterministic?) simulation of the events in the time that they occurred.
Assuming non-negative Game speeds, this might be feasible by using a separate event queue for "game simulation events" (such as collisions or user-input that corresponds to a game-action as opposed to a UI action), and a separate event queue for "real-time events" (such as UI interaction, game-speed changes such as pausing, and any other events that should not rely on game time).
Essentially, this means that there will be separate counters for game time and real time, and each queue will contain events based on a specific time. In addition, game-time will be dependent upon real time.
In order to do this, current partially-working things like pausing, and 'variable game time' may break.
Key press/release events need to get registered at the time they occur, and handled in this order. This would allow for low FPS, but an accurate (deterministic?) simulation of the events in the time that they occurred.
Assuming non-negative Game speeds, this might be feasible by using a separate event queue for "game simulation events" (such as collisions or user-input that corresponds to a game-action as opposed to a UI action), and a separate event queue for "real-time events" (such as UI interaction, game-speed changes such as pausing, and any other events that should not rely on game time).
Essentially, this means that there will be separate counters for game time and real time, and each queue will contain events based on a specific time. In addition, game-time will be dependent upon real time.
In order to do this, current partially-working things like pausing, and 'variable game time' may break.