Hi, me again,
Friends and I wrote a game for PyWeek a few months ago. Since that was
run on a variety of hardware and operating systems, I'm fixing the
reported bugs in it now, with the hope that these bugfixes can be
migrated into my other (and future) pyglet projects.
One of the common reported problems was that, although we create a
pyglet.window.Window with vsync=True, this wasn't honoured in some
cases, resulting in framerates of 400fps or so. This made the game too
fast to play for some people.
I understand that we can compensate for this by scaling all movement by
the delta-time between frames. This has the downside of hogging the CPU,
running many game cycles for every one displayed on-screen.
I wondered if anyone out there has perfected a non CPU-hogging way of
achieving the same thing. Should I detect if fps is greater than a
likely vsync frequency, and then start using clock.schedule_interval()
instead of clock.schedule()?
I don't want to use schedule_interval() by default, because in cases
where vsync does work, I'd rather be synced to the actual monitor
refreshes if possible.
Probably scaling movement by dt still has to happen even when vsync is
working, because different people's monitors might be getting vsync at
50 or 60 or 75fps.
Am I barking up the right tree with these ideas? Thanks for any thoughts,
Jonathan
--
Jonathan Hartley Made of meat. http://tartley.com
[email protected] +44 7737 062 225 twitter/skype: tartley
--
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.
