That way you can draw at 10 or 100 fps even, but the logic still happens at the same rate. Separating out the view and the logic layer is a good idea.
On Thu, Apr 11, 2013 at 11:17 AM, Andre D <[email protected]> wrote: > 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.
