Because I intend for runs through the game to be deterministic, recordable and replayable (by recording user input and feeding it back in). I don't want to any game or drawing logic based on time. Certain events should happen every N frames, and watching for elapsed time allows things to slip through cracks (certain frames are "dropped" in a sense).
On Wednesday, 10 April 2013 16:50:01 UTC-4, Adam wrote: > > On 10/04/13 20:32, Peter B wrote: > > I'm trying to make a retro arcade style 2d game, and part of that requires > that I have discrete per-frame logic (rather than based on delta since last > update). For example, almost every visible element is going to be > constantly cycling through 2-4 frame animations. More significantly, I'd > like to simulate slowdown when lots of elements are onscreen; dynamically > changing the FPS limit seemed like an easy enough way to do this, since it > directly adjusts the period limit used in clock.tick. > > I was doing logic every frame through the scheduled update function, and > relying on the "on_draw" method of pyglet.window to redraw after the > scheduled functions completed- my assumption was that each invocation of > "update" would be sandwiched between by two invocations of "on_draw", and > vice versa. > > How should I organize my code? If I schedule my update function for > every 1/60 seconds instead then I don't see how I'd be able to simulate > slowdown without constant descheduling and rescheduling update at different > speeds on each frame from within the update method. > > > On Wednesday, 10 April 2013 14:09:04 UTC-4, Adam wrote: >> >> On 10/04/13 18:48, Peter B wrote: >> >> >> Maybe I'm misunderstanding something, but I specifically WANT to couple >> my game logic and drawing code. Are you telling me that this is no longer >> possible? >> >> On Monday, 25 March 2013 20:21:30 UTC-4, Adam wrote: >>> >>> On 25/03/13 17:23, Peter B wrote: >>> > Pyglet 1.2 alpha DEFINITELY broke the scheduling. I see people asking >>> > the same thing, why the clock.set_fps_limit which previously worked is >>> > now no longer working as advertised, and the response seems to be Oh, >>> > just don't use it, and schedule everything on time intervals. Which is >>> > fine unless you WANT sometime to fire each frame. >>> > >>> > I'd appreciate some explanation of why this happened. >>> > >>> pyglet.clock.set_fps_limit is deprecated >>> http://pyglet.org/doc/api/pyglet.clock-module.html#set_fps_limit >>> >>> If you want something to happen every frame possible then use >>> pyglet.clock.schedule with your update function as was mentioned earlier >>> in this thread. If you want to restrict the frame rate the correct way >>> to do that now is to use schedule_interval and a redraw will occur when >>> that happens assuming your monitor refresh rate is faster than the >>> interval. >>> >> >> What, specifically, are you trying to do? When you schedule something >> on_draw should be called afterwards by the event loop to draw the changes. >> If you want something more tightly coupled then you'll need to schedule >> something to make sure the screen gets refreshed and then run your logic >> from on_draw. >> > > Why don't you keep track of the time since you last moved your sprite and > then only move/animate them when enough time has passed. Eg: > > class MySprite(object): > def update(dt): > self.total_elapsed_time += dt > if self.refresh_time + self.n_sprites_time < > self.total_elapsed_time: > self.move_and_animate() > self.total_elapsed_time = 0 > > I hope that's clear. > > Adam. > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
