Tag Info

Hot answers tagged

20

You want to separate update (logic tick) and draw (render tick) rates. Your updates will produce the position of all objects in the world to be drawn. I will cover two different possibilities here, the one you requested, extrapolation, and also another method, interpolation. 1. Extrapolation is where we will compute the (predicted) position of the object ...


9

I would like to make an exact version of David's answer. Since I copied so much from him, I'm making this community wiki. TL;DR static float ApplyFriction(float value, float friction, float dt) { return value * pow(friction, dt); } Why is it important? It is often good to make approximations. But approximations are only good when they are good. You ...


7

What you mention is a well understood problem in general. The "virtual second" you mention is generall just thought of as a fixed time delta that is updated baed on an accumulator from wall time. The reason some developers use wall time directly is mostly ignorance on their part in most cases, and special circumstances in others. The usual article to link ...


6

You seem to assume that most games aim for 60FPS, but actually it's much more varied than that. Console games tend to be either 60FPS or 30FPS. And games for PCs and other platforms tend to be wildly variable, though often related to the monitor refresh rate (which can be 60Hz, or 70, or 75, etc). The reason you would want to tie game time to real time is ...


5

I'm not entirely sure that you understand what the article means by a fixed timestep. requestAnimationFrame is defined as: Tells the browser that you wish to perform an animation; this requests that the browser schedule a repaint of the window for the next animation frame. The amount of time that passes between each invocation of the function varies ...


5

By default, although XNA tries to work with fixed timesteps, it only uses a best effort policy. Also, later during development, you might want to reduce FPS to 30 or lower (for example, when releasing on X360 or WP7, or after you realize your game is too demanding). If you implement your game assuming a fixed frame rate, you'd better be damn sure that'll ...


5

Your own proposed answer is spot on; to determine the finish time for a car, you take its position on the frame before finishing and its position on the frame after finishing, and determine at what point during that frame it actually crossed the finish line. If (for example) it crossed the finish line at 40% of the way from its previous position to its ...


5

Your game loop code is correct, but your units are all mixed up -- you are effectively setting to your timestep to .00000003 nanoseconds! Your clock is counting in nanoseconds, so your dt should be in nanoseconds. If a clock ticks 30 times a second, it will tick every .033 seconds. There are many nanoseconds in a second, so it will take more nanoseconds to ...


4

If you assume a constant frame rate of 60, your game doesn't work with the same speed with any other frame rate. If your rendering is too slow, the physics will also slow down. Sometimes this is desirable, but usually games are running the physics with constant speed independent of the rendering frame rate. You can change your formulas to use elapsed time ...


4

Do not attempt to replicate the whole game state. Interpolating it would be a nightmare. Just isolate the parts which are variable and needed by rendering (let us call this a "Visual State"). For each object class create an accompanying class which will be able to hold the object Visual State. This object will be produced by the simulation, and consumed by ...


4

The problem with the physic simulations lays on the integration step to solve equation of motion. What you should do is simply to set an error in integration you can accept (ε) then look to your integration algorithm to see for what step size it gives you that error (ε(Δt)); let say that this error is Tmin. Now if your elapsed time ...


4

Looking at your second log file, I'm wondering if you're calling resetSmoothStates() in the right place? On lines 42, 46, 50, and 54 you can see that the original position stays at a constant [661.2183], indicating there hasn't been a physics update. On line 43, it looks like you're smoothing between the previous original position, [671.2361], and the new ...


4

Do I need to supply my physics stepping with some sort of delta variable? Should I even be using GameTime.ElapsedGameTime anywhere in my code? Yes, you should. I'm not sure if XNA have a fixed timestep in 60fps, but even if it does, the fps may drop and you wont be able to do nothing about it, so that's why it is better to still use ...


4

FixedTimeStep is about as advanced as you can make such a routine, it gives you (by default) 60 updates a second regardless of if you have 10fps or 100fps, it will also gracefully handle debugging without locking your machine up (the loop you refer to would naively try to catch up to all the lost frames, causing an interesting cascade effect and loss of fps ...


4

You are probably updating the velocity twice, since this is usually done in the integration step itself. I expect you implemented the RK4 integration from http://gafferongames.com/game-physics/integration-basics/. The author defines Derivative.dv as the acceleration (derivative of velocity) and State.v as as the velocity In the evaluate function you can ...


4

Frames Per Second (FPS) should be just that. The number of frames drawn every second. What FPS is not is something that you should be basing your gameplay timings around. You are running into issues when spawning enemies according to elapsed time because the rest of your game is not based around time, I bet. In your current setup I imagine you are updating ...


3

In your code snippet it looks like you're trying to run your game in fixed-time step mode by busy-waiting if your drawing and updating took less then 15ms (60fps). This is possible and you guessed right that this can't be done using a sleep call because you don't exactly know how long you're going to sleep. The busy-waiting-loop is the good solution. ...


3

XNA (in fixed time mode) will try to call you 60 times per second, but that doesn't mean that the calls are always 1/60th of a second apart. GameTime will tell you how much time has elapsed since the last call, and you should use that to feed into any time-sensitive calculations.


3

Problem: Your computer can achieve the target fixed physics framerate, but your phone cannot. Solutions: Reduce the physics framerate (Increase FIXED_TIMESTEP). Reduce the physics calculations needed per frame. Do you absolutely need interpolation? Just render the uninterpolated state. Interpolation is only for making the rendering look smoother. ...


3

My solution far less elegant/complicated than most. I'm using Box2D as my physics engine so keeping more than one copy of the system state isn't manageable (clone the physics system then try to keep them in sync, there might be a better way but I couldn't come up with one). Instead I keep a running counter of the physics generation. Each update increments ...


3

Basically you have three ways to periodically invoke some code. have a infinite loop with sleeps. use setIntervall to perodically be waken use requestAnimationFrame for when the browser is idle Although this is about animation, it covers the basic crux of the problem: Animating In Code Using JavaScript


2

Obviously I will need to store (where?/how?) two copies of game state information relevant to my renderer, so that it may interpolate between them. Yes, thankfully the key here is "relevant to my renderer". This might be no more than adding an an old position and a timestamp for it into the mix. Given 2 positions you can interpolate to a position ...


2

I've heard this approach to timesteps suggested quite frequently, but in 10 years in games, I've never worked on a real-world project that relied on a fixed timestep and interpolation. It seems generally more effort than a variable timestep system (assuming a sensible range of framerates, in the 25Hz-100Hz sort of range). I did try the fixed ...


2

Your formula is wrong, as 0.5*accel*t^2 gives a change in position, not a change in velocity. What you probably want to do is this: gravity = new Vector3(0, -9.81f, 0); projectileVelocity += gravity * gameTime.ElapsedGameTime.TotalSeconds; projectilePosition += projectileVelocity * gameTime.ElapsedGameTime.TotalSeconds; Note that the framerate of 60 is ...


2

I'm leaving this post as reference and context for Sam's answer, but you should use his version instead. TL;DR Here's your function (in C#) where I took the liberty to add the friction as a parameter instead of hard-coding it: static float ApplyFriction(float value, float friction, float dt) { return value - value * (1f - friction) * dt; } You ...


2

There is a wrong assumption behind this question which leads to a solution that is not well prepared for real world requirements. Don't ever count on a consistently stable frame time X, unless you are on a Real Time Operating System. The usual gaming platforms don't fall under this category. On all other systems the frame time is not deterministic (even if ...


2

I see several issues with your code: First, your update loop never sleeps, it just busy-waits until enough time has passed. While this shouldn't actually cause any problems in your example (other than possibly overheating your CPU), it would be a problem if you wanted to do anything useful in some other thread at the same time. Also, it's just plain ...


2

The precision should be precise enough to meet your requirements. Your requirements may allow for some missed updates now and then. Your requirements may allow only high-end hardware. It's up to you to find the balance between resource usage and precision. The precision will vary from genre to another, from one game to game and even from one game mode to ...


2

A CADisplayLink does indeed do framerate limiting. Under normal operation, you will never get -render: messages any faster than the display's refresh rate. I'm not sure what the standard practice for doing game logic in -render: is, but I can tell you two things: one, CADisplayLink was not designed to run both your rendering and your game logic, and two, ...


2

Gordonk was absolutely spot on. It now appears that I have silky smooth movement at 60fps. If I cap the frame rate at anything less than 60 I start to see serious stuttering, but I guess that's a separate issue to explore. So here is the code I am using right now. It hasn't been optimized in any way, it was just to implement a fixed time step. I'm using the ...



Only top voted, non community-wiki answers of a minimum length are eligible