Hi. While writing tests for the pyglet clock, I found what I believe to be a relevant problem to be discussed here.
As you know, pyglet clock works with the concept of ticks. Since ticks are discrete and time is continuous, this brings some problems. One main issue is that the tick rate is not constant. This means that, if we want to schedule a function to be triggered at fixed time intervals (clock.schedule(func, time_delta)), we need a way to decide how it is triggered. To make it clearer: |---------|---------|-----------|--|----------------|-----------|----------> the ticks (each "-" means 10ms) *-----*-----*-----*-----*-----*-----*-----*-----*-----*-----*-----*-----*> the scheduled item (delta_t = 50ms) In some situations the tick happens for each trigger, but other situations lead to more than 1 trigger per tick, or no triggers per tick (as exemplified in the figure). The way it is currently implemented, there are two problems; one explained in this issue <https://code.google.com/p/pyglet/issues/detail?id=691> (which reports that there are less calls than expected), and the other is described below. What is the current implementation? Lets consider the example above (code in clock.call_scheduled_functions). A scheduled item has an attribute next_ts, which dictates the next trigger (a * in figure above), and the last_ts, which stores when was the previous trigger. When a tick happens (the | in the figure, "ts" in the code), if next_ts > ts, we don't trigger. Else, we trigger it and do next_ts = last_ts + interval last_ts = ts It can happen that the new next_ts is still smaller than ts, the case on which it would be require to trigger another call. Instead, we avoid "lumping everything together" (comment from code) using a code to set next_ts to some value (that I was not able to follow) AND change last_ts = next_ts - interval which, by a comment in the code, "Unfortunately means the next reported dt is incorrect". I feel that this problem is related with the fact that we are trying to trigger calls separated by a fixed time interval (schedules) by a variable time interval (ticks), *avoiding double calls per tick*. I don't know if this is a feature, or a bug, but I didn't found it documented. Given these two limitations, I propose the following: instead of doing next_ts = last_ts + interval last_ts = ts we do while next_ts < ts: # call function with dt=interval next_ts = last_ts + interval last_ts = ts # drop rest of code for getting "correct" next_ts What this is doing is to ensure that if it was supposed to be N calls before the current tick (ts), we call them until the next_ts is after the tick (ts). This *allows more than one call per tick*, but guarantees that if the scheduled time-interval is 1/30, in 1s we trigger 30 calls, which I believe is the user expectation. Taking into consideration that the current schedule functions are 1. schedule every tick 2. schedule with fixed time-intervals 3. schedule fire and forget events If we really want to keep a schedule driven by ticks, we can add a 4th option for scheduling a callback: 4. schedule with fixed tick-interval (e.g. triggers every 5 ticks). What do you think? Cheers, Jorge ;-) -- 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. For more options, visit https://groups.google.com/groups/opt_out.
