On 9/17/08, Elmo Trolla <[EMAIL PROTECTED]> wrote: > > > 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).
Well, I don't quite agree with your premise, but anyway... You can get _exactly_ the monitor refresh rate fps using clock.schedule() and vsync=True. Surely you'd prefer to run at 75 fps on a 75 Hz display, to avoid duplicating frames (and creating jitter). Using schedule_interval and invalid=False, you should get quite close to the desired framerate (it's actually pretty spot on on Linux and OS X, and slightly behind on Windows). Note that this at least guarantees on_draw() will not be called more often than 60 fps. > > 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. You should be setting it to True in the on_draw handler. > More than 30fps makes sense if the game has physics that is not > decoupled from the framerate. Everything I do : / FWIW, my latest PyWeek entry (http://pyweek.org/e/midnightsun/) is physics-based and runs at 30 FPS using the method described above (schedule_interval + invalid flag), without interpolation, and doesn't seem to exhibit any jitter on slow or fast machines. Alex. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
