I think it will help if you consider `pausing' a separate aspect that
isn't intertwined with the event loop. For example, the action of
pausing could result in a flag being set on a physics engine which
stops updating positions on managed objects. Or you have intermediary
event handlers (maybe a function decorator - @pausable) which obey a
global paused flag and block inputs to certain objects, etc. Exactly
what you do depends on the structure of your application, but in any
case. you're better off not coupling a high-level application concern
such as pausing with low-level event handling. Hope this helps.
Cheers,
--
\\\\\/\"/\\\\\\\\\\\
\\\\/ // //\/\\\\\\\
\\\/ \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\ /\\\ \\
/ /\\\ /\\\ \\\\\/\
\/\\\\\/\\\\\/\\\\\\
doryuu
If you had a single update method for game behaviour then you could just
unschedule it.
Richard
You are correct if they're individually scheduled.
Richard
-Casey
You know, it's not all that hard to write your own scheduler that does
things the way you want. The one in Rabbyt is only 10 lines of code or so.
MWM
For my PyWeek entry, I created a game clock (another instance of
pyglet.clock.Clock), with a custom time function that returned the
game time. The game clock is then manually ticked by the global clock
only if the game is not paused. In this example a fixed timestep is
used on the game clock, which is useful for collision detection.
class Game(object):
game_time = 0
accum_time = 0
update_t = 1/60.
def __init__(self):
self.clock = pyglet.clock.Clock(time_function=lambda: self.game_time)
pyglet.clock.schedule_interval(self.update, self.update_t)
def update(self, dt):
if self.paused:
return
# Align updates to fixed timestep
self.accum_t += dt
if self.accum_t > self.update_t * 3:
self.accum_t = self.update_t
while self.accum_t >= self.update_t:
self.game_time += self.update_t
self.clock.tick()
self.accum_t -= self.update_t
Now just remember to schedule game events on the game clock, and
real-world events on the pyglet clock (usually just menu animations).
Alex.
If think rather than writing you own scheduler, proxying the main one
is better (for some use cases). pyglet has support for more complex
media event scheduling (schedule_interval_soft) to prevent trampling
the CPU, for example. Also, by proxying per scene/level in the
context of the game you can keep references to things scheduled in the
context of a scene/level and prevent accidentally leaking references
by: 1) "noop"-ing on schedule requests after a scene is completed and
2) explicitly tracking/unscheduling functions scheduled in the scene.
Just my two cents on this.
--
\\\\\/\"/\\\\\\\\\\\
\\\\/ // //\/\\\\\\\
\\\/ \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\ /\\\ \\
/ /\\\ /\\\ \\\\\/\
\/\\\\\/\\\\\/\\\\\\
d.p.s