Clamp delta time in debugger, or other ways to control delta_time

[cspotcode]

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_time will 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) or set_fixed_delta_time or maybe there's something more auto-magic that would allow detecting when the debugger has paused? if sys.gettrace() is not None

AI

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_time but for arcade to tick as fast as possible, no sleeping.

[gran4]

Maybe the AI section could be a separate issue?

[pushfoo]

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.

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.

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:

• @DragonMoffon started on some experimental clock-related work over in arcade/experimental/clock, but it's in a very rough state.
• There's some capacity for custom event loops in pyglet which I haven't had time to fully investigate yet