I do not understand why this is an issue, can you not schedule a tick for 1/LOGIC_TICKS_PER_SECOND which sets the current animation frame, then in the drawing code, just draw those currently selected frames?
On Wed, Apr 10, 2013 at 5:21 PM, Adam Bark <[email protected]> wrote: > On 10/04/13 22:09, Peter B wrote: > > 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<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. >> > > It doesn't have to happen at a certain time it just happens whenever the > next frame occurs after a set time has elapsed so nothing gets "dropped". > It will do exactly the same as limiting the frame rate. Alternatively you > could "schedule_once" your update function on each frame as long as you can > determine how long it should be 'til the next frame. > > -- > 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. > > > -- 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.
