On Sep 16, 2008, at 5:12 PM, Alex Holkner wrote:
>> ----
>>
>> opengl_clock_schedule_interval.py
>> pyglet.clock.schedule_interval(update, ..)
>>
>> #
>> # param : fps cpu cpu while mousemove cpu after move or resize
>> # :
>> # 1/30. : 21 0% 3% 20..23%
>> # 1/60. : 32 0% 3% 32..39%
>> # 1/100.: 64 0% 3% 58..63%
>> # 1/200.: 64 0% 3% 62..75%
>> #
>> # no change if i move the window, or move mouse inside the window.
>> #
>
> These results are surprising (and don't match mine at all). You
> should see far higher FPS readings for the code you supplied for
> intervals 1/100 and 1/200; because the event loop degenerates to
> polling in this case (by design). For the 1/30 and 1/60 cases you
> should also see framerates far above the target interval.
Hm. Now I'm interested. I'll find what's wrong with my computer by
tomorrow..
> Note that to actually achieve the target framerate, you should set
> window.invalid to True in on_draw(), and to False in update().
Not if I render in update() and overload the flip() method : )
Why I would want that:
For my little hobby-games/programs I make the assumption that every
computer worth supporting can run the program at 60fps. 30fps and
animating non-blurry graphics is too ugly for me. I just can't stand
it. And since I'm too lazy to decouple game-physics from framerate and
use interpolation to get updated positions in the renderer, I have no
other choice but to run *everything* at 60fps. (sadly physics has to
work with a fixed timestep. no other way).
Once I made the 60fps decision, there's no need for externally
generated on_draw events (resizing the window, moving something over
the window..).
Btw, the on_draw event is always triggered twice at program startup.
Once for resize, once for move (told by WindowEventLogger). Setting
window.Invalid to False on window constructor has no effect.
> This gives approximately the target framerate on my machine (slightly
> under, actually). There's definitely room for improvement if someone
> wants to write a better clock function, ideally using a better
> integration function, such as phased lock loop, to correct for jitter
> over longer time periods than the current implementation. I
> personally don't see this as a big necessity though -- developers
> should either be targetting low framerates (below 30) or the refresh
> rate (enable vsync); anything else just doesn't make sense.
More than 30fps makes sense if the game has physics that is not
decoupled from the framerate. Everything I do : /
> I'm not interested in attempting to make set_fps_limit work with the
> event loop; so long as it degenerates gracefully (as it seems to now)
> I'm happy -- the function is deprecated in favour of scheduling on the
> clock.
Agreed. I just included the example in hopes it would give some ideas
for the schedule_interval problem.
>> ----
>>
>> opengl_custom.py
>> This has my own main-loop. Compare cpu usage.. And animations really
>> are as smooth without vsync as with (ok, some occasional tearing, but
>> absolutely no jumping).
>>
>> #
>> # fps_dt : fps cpu
>> # :
>> # 0. : 3400..3600 70..82%
>> # 1/60. : 60 0%
>> # 1/100. : 100 0%
>> # 1/200. : 200 0%
>> # 1/400. : 400 0..20%
>> # 1/800. : 800 50..76%
>> #
>>
>
> This event loop isn't very general: it only works for one window, and
> doesn't let events preempt the loop; making it ultimately more latent
> than the pyglet event loop, unless your application is
> non-interactive. It also doesn't run while windows are being moved or
> resized, or while menus are being tracked on OS X.
Latency and preemption are not a problem for 30-60fps programs
(usually.. But if someone has a 200Hz mouse, some of the coordinate
post-processing potential might be lost due to the mousemove events
having no timestamp. I don't know if the mouse example even makes
sense : ). I'll try to find out if the preemptive loop can be made as
smooth as my own loop under windows. Maybe it can't in principle..
Maybe there'll always be a choice between a general event loop, and a
smoothest-possible-animation single window event loop. I'm not sure of
anything yet. But thanks for the explanation.
>> Some of the jumpiness can be traced back to
>>
>> pyglet.clock.tick()
>>
>> returning too big values ~4 times per second (if the program runs at
>> 60fps), and too small values rest of the time. Using standard time
>> module
>>
>> dt = time.clock() - prev_clock
>>
>> is much more precise.
>
> Is this due to pyglet.clock using time.time() instead of time.clock()?
Yes. I changed time.time to time.clock in pyglet/clock.py
class Clock...:
def __init__(self, fps_limit=None, time_function=time.time)
and now the set_fps_limit version of opengl.py is exactly as smooth as
my own main loop, and the other versions are smoother than before.
But that's only windows-specific. time.time should be used on linux
and macosx. python-list has some discussions that explain it better
than I could. Keywords are time.time, time.clock and time.sleep.
(time.clock can jump backwards in time sometimes (i've never seen it
jump more than a few ms). but so can time.time if someone decides to
change computer date while pyglet is running)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
