On Jan 5, 5:35 pm, Casey Duncan <[email protected]> wrote: > On Tue, Jan 5, 2010 at 2:04 AM, Hello3171 <[email protected]> wrote: > > > On Jan 5, 1:14 am, Ryan <[email protected]> wrote: > >> 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 > > > | Are there other reasons you to update at constant timestep? Just > > because it's generally complex to update the model under variable > > timesteps? > > [other than rigid body simulation] > > > If you are doing any kind of simulation then it is important to have a > > constant timestep. For example, in my own game I implement gravity > > around different objects. If I didn't have a constant timestep then my > > movement code would look something like this: > > > x += calculated_final_velocity*dt > > #(versus:) > > #x += calculated_final_velocity > > #or > > #x += calculated_final_velocity*constant_adjustment_factor > > > If dt becomes too large then the object will continue in that same > > straight line for a much longer distance. If dt was smaller then the > > path would be more curved. Against different timesteps they travel > > different paths and the entire simulation can become different. > > This is particularly important for multiplayer games and if you were > > to allow demos to be recorded. Additionally, if you implemented simple > > collision detection then the results will also vary. > > > But there is a problem with a constant timestep: Ideally the constant > > timestep would be large enough to allow the simulation frame to > > complete on all computers with time to spare for rendering, if it > > doesn't then you simply cannot play the game. It is hard to reduce the > > power required for the simulation variably without affecting the > > simulation itself. This sets a minimum requirement for your game which > > might have otherwise been less for a variable timestep. > > > If you don't intend to allow multiplayer/sharing simulations then a > > variable timestep may be better. But you should be aware of situations > > where it may make your game unplayable. > > You may find this illuminating: > > http://gafferongames.com/game-physics/fix-your-timestep/ > > -Casey
Many thanks to everyone for the advice and the links. Yesterday I read it all very carefully, and today I'm percolating on it. Clearly, for my little simple 2D sprite game (this is the sinister ducks game), I don't need to go the whole hog of the RK integrator with interpolated rendering positions, which seems to be the logical conclusion of this process. I can see that while simply varying the speed of motion by the dt between frames will help to run the game at a desired speed, like any sort of numerical integration, it will have unwanted side effects due to changes in sampling errors for different values of dt. eg. Duck flaps would be noticeably stronger or weaker if fps is varies from 30fps to 400fps, depending on hardware. I'll hack up a quick and dirty fixed timestep for the sake of bugfixing Sinister Ducks, but will bear this prominently in mind for future projects.
-- 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.
