The thread "Monitor resolution & blit_into alpha" has some discussion  
about this problem (starts about half-way through):
http://groups.google.com/group/pyglet-users/browse_thread/thread/14579ad0e3e577a1/060216fd28106152

Basically, under windows, the culprits are functions time.time() and  
_user32.SetTimer(). For some reason, on some computers, the precision  
of these functions is way too low. If you try the following program  
and the output is anything below.. say 300, you are in trouble : (..

import time
p = 0.
while 1:
      t = time.time()
      if t != p: print "timeupdates/s", 1. / (t - p)
      p = t

...
timeupdates/s 62.4998733404
timeupdates/s 66.6662004292
timeupdates/s 62.5008046731
timeupdates/s 66.6662004292
...

time.time() updates only ~64 times per second on my computer.

It would be interesting to know what percentage of computers has this  
problem. I've tested it on only two computers, and both have this  
problem (core2duo, corequad).

For now, your best bet is to write your own main-loop. Something like  
in this example:
http://etm.blastnet.ee/var/list/opengl_custom.py

But my example only works smoothly on windows (jumps and jitters on  
linux and macosx) and has some other limitations (nothing works while  
you drag the window around in any os, or navigate the menu-bar in  
macosx).



On 26.10.2008, at 3:38, dabski wrote:

> Thank god or should I say dirkjot for finally pointing this out, I was
> wondering why my game was running faster on my friends computer which
> even though it is faster than mine I am limiting update to 60 steps a
> second. I did some tests of my own by adding in a a global counter
> into the update loop and printing out the total count for 30 seconds
> then dividing the total count by the time. My game is running at
> approx 15 steps per second instead of 60 and his is running it at
> close to 50. Not being sure if it was something to do with Python as I
> just recently started learning it I added the counter into someone
> else's application and it came back with similar results showing that
> clock.schedule_interval function dose not appear to work correctly.



--~--~---------~--~----~------------~-------~--~----~
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