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 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.
