Clamp delta time in debugger, or other ways to control delta_time#1543
Clamp delta time in debugger, or other ways to control delta_time#1543cspotcode wants to merge 1 commit intopythonarcade:developmentfrom
Conversation
|
Maybe the AI section could be a separate issue? |
|
TL;DR: The root issue is still the same: customizing frame / event loops @FengchiW Since you mentioned being interested in dealing with #1137, i'm tagging you here.
Arcade (and pyglet) having poor delineations between system time and game time contexts have hurt us before. One example is a crash when debugging under PulseAudio (#1900) due to an issue with upstream (pyglet/pyglet#952). What I know at the moment:
|
|
We have the new Clock API now, i will just add the ability to set a clamp on the clock's delta_time that way, it needs to check only once for debug and can be changed at run time (in response to a lag spike, for example) |
4 participants
There are a few different cases where it might be helpful to clamp or control
delta_time.Debugger
When pausing in the debugger, the next frame's
delta_timewill be massive. Makes sense, if you pause the debugger for a minute, then the delta is 60s.But engines like Unity clamp delta time for this reason. When you pause and then resume the game in Unity, it will not generate a massive
delta_time.Should we add something like that to arcade?
It could be as simple as
my_window.set_max_delta_time(1/30)orset_fixed_delta_timeor maybe there's something more auto-magic that would allow detecting when the debugger has paused?if sys.gettrace() is not NoneAI
I can't speak to this one, but people want to use arcade for AI simulation or visualization. In these cases, I think the simulation and render loop should run in fast-forward, as fast as the CPU can handle. We can update docs to explain how to do this easily. Maybe we explain how to set a fixed
delta_timebut for arcade to tick as fast as possible, no sleeping.