RE: [Algorithms] Game loop timings
Brought to you by:
vexxed72
From: Jon W. <hp...@mi...> - 2005-04-08 16:39:34
|
> > With a good enough physics timestep, you don't need to. Physics at 100 Hz > > and "free running" frame rate around 25-35 (depending on machine/card/etc) > > seems to work just fine in my tests. > Hmmmmm.... have you tried locking the fps at e.g. 30 and forcing gfx to sync > to refresh (so you don't have screen tearing)? You should be able to see > stuttering on a steadily moving object in this situation (30fps vs 100Hz If you're perfectionist, certainly interpolating will look better (this also depends on scene type). > Console is one of the reasons tripple buffering is not an option. Hardcore > FPS gamers are another reason. Input-to-render latency and twitch games just > don't go together. Hard-code PC FPS players will turn off vsync at all, right? Do you find there's a market for hard-core FPS players these days? Back when I tried it, I came to the conclusion that mouse and FPS were made for each other. > In a previous FPS project, I implemented fixed timestep for physics, AI, > controls and networking. It was simple and it worked. Used 20Hz for > timestep, interpolated the graphics. Everyone said the thing was very nice > and fast, and that it looks very, very smooth. Then we brought in a Quake > player who does competitions etc, to let him check it out. After a few > seconds running around, jumping like crazy and twitching the mouse > left-right, he said: "this is wrong". It took some time to figure out that Do you think the 20 Hz command rate has something to do with it? I think that with a fast physics rate/command rate, that'd be solved. > Moral of the story: don't introduce latency where you don't have to. I'm with you there. > 1) Tunneling. IMO, solving tunneling by increasing physics rate is a bad > idea. To prevent tunneling, you need sweeping. Period. Integration I agree -- you need to sweep if you move further than your maximum acceptable penetration depth in a single frame. > 2) Articulated systems. For a simple example, rotation of a body connected ... > correct it. This is the primary reason for small timesteps. And it is > perfectly valid. But it has nothing to do with collision, and it can be > separated from collision rate. I would argue that the interaction between those bodies may cause collisions at each of the time steps, so colliding at each time step is preferable. This might be one of those "horses for courses" things, though. (you know the absolute law of the universe: everything depends) > So, a rocket is going to explode at one timestep, and inflict damage to all > objects in range, and the damaged AIs are going to handle the damage event a > few timesteps later? The damaged AI is going to make a new decision about what its goals are a few steps later, yes. Most humans don't have infinitely fast reaction times, after all :-) If you damage something enough to kill it, well, death doesn't need lots of cycles (mostly just queuing notification messages). Is yours different? (I've kept our specific challenges out of this, like our opposing forces come from the OneSAF Objective System, which delivers entity data to us once every three seconds or so. Frame latency just isn't the biggest of our problems at that point :-) > > time step. So, if someone's asking me "how do I do this" then I'll > > probably keep saying that "the easiest way I've found is ..." > I'm saying is that if you are going to do a real game with it, you need to > weight your requirements and see which is better for you, fixed or variable. Fair enough. Hopefully now "igrok" (the original poster of this thread) has enough data to support his decision one way or the other. Cheers, / h+ |