Just as a follow-up .. this is what I'm currently using to limit FPS
in my game .. although, note, it -is- `blocking' (events caught in-
between frames don't get processed immediately).. it's basically just
a busy-loop:
def sleeper( duration, dt ):
if dt: duration -= abs( dt - duration )
duration += pyglet.clock.time.clock()
while True:
if pyglet.clock.time.clock() >= duration: return
assuming you have `import pyglet`d .. and that it's called from within
a `schedule[_interval]()`d event (ie, _not_ `on_draw()`), with the
following syntax:
sleeper( 1.0 / FPS, dt )
On Sep 10, 3:29 am, 3TATUK <[EMAIL PROTECTED]> wrote:
> hmm... yeah, this looks really good indeed. It's in-depth and
> precise.. The only thing I'd like to tag on as a comment to you and
> Alex when looking into implementing any of these changes is a way to
> make this non-blocking, and render-specific.. meaning... any events
> (mouse/keyboard) or other functions scheduled to happen in between the
> rendering of two frames should happen exactly then, instead of waiting
> for the frame to render. :) really nice work!
>
> On Sep 9, 8:09 pm, Elmo Trolla <[EMAIL PROTECTED]> wrote:
>
> > > On Tue, Sep 9, 2008 at 1:27 AM, 3TATUK <[EMAIL PROTECTED]>
> > wrote:
> > > > ...
> > > > At this point it's kind of pre-mature optimization because pyglet
> > has
> > > > serious FPS issues as it is.
> > > > ( seehttp://code.google.com/p/pyglet/issues/detail?id=341)
>
> > > Pyglet does not have serious FPS issues. set_fps_limit() is
> > > deprecated. If you want an almost constant FPS, write your own event
> > > loop with blocking clock ticks. Otherwise, schedule your animations
> > > and be happy.
>
> > > -Drew
>
> > Writing a good main-loop is not simple - mine took many days and is
> > still not perfect. I hoped pyglet will do this work for me, since
> > everything else seems really well thought out. Thanks :) But
> > considering main-loops - all examples that come with pyglet have some
> > issues (at least under windows. pyglet version 1.1.1 2224 2008-08-26).
>
> > Pyglet 1.1 has the new application event loop. Docs recommend using
>
> > clock.schedule_interval(update, 1/60.0)
>
> > to get 60fps, and
>
> > clock.schedule(update)
>
> > to get max fps. Neither works, as fps is not even near the desired
> > fps. Trying to use the deprecated
>
> > pyglet.clock.set_fps_limit(60)
>
> > results in jumpy animations (if vsync is off) and too high cpu usage.
> > Now what..
>
> > I've created four test-programs, each one a slightly modified version
> > of the pyglet-1.1.1-docs.zip opengl.py example. WinMerge can be used
> > to quickly see the differences between these versions.
>
> >http://etm.blastnet.ee/var/list/opengl_clock_schedule.pyhttp://etm.bl...
>
> > And here are the results I got: (copy-pasted from the py files)
>
> > ----
>
> > opengl_clock_schedule.py
> > pyglet.clock.schedule(update)
>
> > #
> > # after startup : 64 fps 0% cpu
> > # while moving mouse inside the window: 143..149 fps, 3% cpu
> > # after window resize or move : 3300..3500 fps, 60..70% cpu
> > (and stays this way)
> > #
> > # (core2duo e8200, nvidia 8800gt, xp sp2. 50% cpu means 100% of one
> > core)
> > #
> > # window.invalid = True has no effect on fps
>
> > ----
>
> > 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.
> > #
>
> > ----
>
> > opengl_fps_limit.py
> > pyglet.clock.set_fps_limit(..)
>
> > #
> > # limit : fps cpu
> > # :
> > # 0 : 3400..3600 70..82%
> > # 1/30. : 29..60 14%
> > # 1/60. : 59..60 28%
> > # 1/100. : 99..102 44%
> > # 1/200. : 180..185 50%
> > # 1/400. : 126..130 50%
> > # 1/800. : 126..130 50%
> > #
> > # fps was NOT stable. even changing between 59..60 means jumpy
> > animations.
> > #
>
> > ----
>
> > 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%
> > #
>
> > ----
>
> > Sadly I chose a bad example. Problems would've been much more visible
> > on a big rotating checkerboard. Well, until next time..
>
> > 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.
>
> > I'll see if I can find something in pyglet source.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
