On Jan 4, 1:16 pm, Jonathan Hartley <[email protected]> wrote: > On Jan 4, 5:46 pm, Tristam MacDonald <[email protected]> wrote: > > > > > > > The "best" way to do this is to fix your update at a constant timestep, say > > 30 updates per second. Then the rendering can go at whatever speed it likes, > > and just extrapolate/interpolate to get the intermediate locations. > > > This doesn't solve your issue of hogging the CPU, but keep in mind that lots > > of gamers just like to leave vsync off and see how high it can go ;) > > > Tristam MacDonaldhttp://swiftcoder.wordpress.com/ > > > On Mon, Jan 4, 2010 at 7:02 AM, Jonathan Hartley <[email protected]>wrote: > > > > 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 > > Right, thanks. I can see that constant update timestep is desirable if > you have rigid body simulation involved - they don't seem to like > variable timesteps. Are there other reasons you to update at constant > timestep? Just because it's generally complex to update the model > under variable timesteps? > > I guess if the user has set video driver config to disallow vsync, > then my responsibility to honor that explicit choice is greater than > my general responsibility to try and not hog the cpu. So I'll just run > fast, scaling movement by dt per frame. > > Thanks for giving me someone to bounce this off. > > Jonathan
You might find this interesting: http://dewitters.koonsolo.com/gameloop.html -- 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.
