Just to chime in on this, I've also been having similar issues with  
clock timing on Windows lately, so I did some investigation on Win/Mac/ 
Linux using something similar to this to judge the actual calls-per- 
second (CPS) of a scheduled function (changing time.time to time.clock  
makes no difference here also):

import pyglet
import time

cps = 30.
last_time = 0.
time_diff = 0.
def update(dt):
     global last_time, time_diff
     time_diff = time.time()-last_time
     last_time = time.time()

def show_cps(dt):
     print 1./time_diff

pyglet.clock.schedule_interval(update, 1/cps)
pyglet.clock.schedule_interval_soft(show_cps, 1.)
pyglet.app.run()

I always get the requested CPS on Mac and Linux. On Windows however,  
the cps varies between different machines - on some it is always about  
50% of what I ask for just as Gachuk reported, and on others it is  
slower by a % of the requested amount, e.g. 30cps actually runs at  
25cps, 60cps actually runs at 50cps, 100cps does run at 100cps but  
120cps also runs at 100cps?!?! I need to ensure that some non-drawing  
functions get called at a minimum frequency, and at the moment its a  
matter of trial and error to get it right.

Is this down to something funny in Window's scheduling functions, or  
just the way that Pyglet uses them? As I said earlier, I don't see  
these problems on either Mac or Linux. Could other people run the  
above code for various values of 'cps' and see if they also observe  
the same behaviour? Doesn't seem to matter which version of Pyglet/ 
Python I use.

Thanks,

Padraig

On 26 Jun 2009, at 08:30, Gachuk wrote:

>
> Hi,
>
> Thanks for the reply, yes I understand that it won't be exactly 16ms,
> but it does seem odd that I don't get it at all and get 30ms
> consistantly (unless I have another app that might interfear).
>
> I suppose there is no actual need to fix it at 60fps, but I assumed
> with just scheduling everyframe it will just consume as much as
> possible. Additionally all the examples/docs generally suggesting
> updating at an interval in preference.
>
> I will continue to investigate a little more but perhaps I will fall
> back to your suggestion if I can't get to the bottom of it.
>
> Thanks
>
> Gachuk
>
> On Jun 26, 12:47 am, Tristam MacDonald <[email protected]> wrote:
>> On Thu, Jun 25, 2009 at 5:55 PM, Gachuk <[email protected]>  
>> wrote:
>>
>>> Hi,
>>
>>> I've been having a strange timing problem, with the following code I
>>> expect to get around 16ms as the deltatime instead I get around  
>>> 30ms,
>>> this is not just variance it is consistantly 30ms, which would imply
>>> it's not updating at the correct speed.
>>
>>> ###
>>> import pyglet
>>
>>> # App Entry point
>>> def main():
>>>    def update(dt):
>>>        print dt
>>
>>>    pyglet.clock.schedule_interval(update, 1/60.)
>>>    pyglet.app.run()
>>
>>> if __name__ == "__main__":
>>>    main()
>>
>>> ###
>>
>>> I am running this on the latest source from the trunk (although i  
>>> also
>>> tried 1.1.3) a QuadCore Intel 64bit windows 7 build, but I have
>>> experienced the problem on other machines. However a friend on a mac
>>> ran it and said he did get 16ms and I've had others on windows XP  
>>> also
>>> tell me it's running at 16ms
>>
>>> What is interesting is that if I start certain other applications,  
>>> the
>>> timing gets more accurate. Someone suggested to me it might be to do
>>> with the applications I start using timeBeginPeriod/timeEndPeriod
>>> which could apparently effect globally. See
>>> http://www.virtualdub.org/blog/pivot/entry.php?id=106
>>> for more info on that.
>>
>>> I have noticed that the trunk version uses time.clock() now  
>>> instead of
>>> time.time() although it makes no difference eitherway.
>>
>>> I would appreciate any ideas about this.
>>
>>> Thanks in advance
>>
>>> Gachuk
>>
>> Unless you have a definite need to fix your frame rate at 60 fps, I  
>> would
>> suggest you use schedule() rather than schedule_interval, and let  
>> the vsync
>> limit your frame rate to the actual monitor refresh rate.
>>
>> As for the variable delta, scheduling tends to be more of an 'at  
>> least 16
>> ms' than an 'exactly 16 ms', since you are at the mercy of the OS  
>> scheduler.
>>
>> --
>> Tristam MacDonaldhttp://swiftcoder.wordpress.com/- Hide quoted text -
>>
>> - Show quoted text -
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to