41–50 of 86 posts
Of course, you will need to update the initial position/velocity/time whenever the jump is interrupted or modified. The reduction in error is also quite small.
This isn't exactly a new development, as the article in question was first posted on May 13th, 2000.
Earlier quoted context omitted.
Yeah, in the perfect world all your buyers will have them. In real life sometimes don't. Plus there is a lot of things you don't know; maybe he haves the minimum requirements but he is running a lot of background process because he installed a bunch of things he doesn't use.
If the game is so bogged down that the fixed timestep cycle is slowing down the game is broken for so many other reasons. Objects will start tunneling through other objects.
Earlier quoted context omitted.
> Drops in framerate happen. No, they don't. Game logic should run at constant 60 or more fps, even when graphics framerate is lower: http://gafferongames.com/game-physics/fix-your-timestep/ But yes, it's an interesting article, and this method allows for a bit more accuracy.
So, why is it important to have a fixed deltaTime? Except in cases where determinism really does matter. I.E. lock-step based networking. Why is this important?
Earlier quoted context omitted.
So, why is it important to have a fixed deltaTime? Except in cases where determinism really does matter. I.E. lock-step based networking. Why is this important?
Determinism really does matter. You want it for debugging. Also for replays, if your game has that feature.
Sure, it makes some things easier, but it comes at some cost.
This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/
Which is why decoupling the physics delta from the rendering framerate is important. The author mentions Quake (id Tech 1, 2 or 3 ?), and I seem to recall id Tech 4 (Doom 3) was the first id Tech engine that implemented that.
you are still doing it wrong. dt should not be affected by framerate. http://gafferongames.com/game-physics/fix-your-timestep/ use an accumulator to have a fixed dt no matter the framerate. With a variable step size you risk all kinds of weird bugs linked to the hard to debug rendering context. The size of dt should be consider a system parameter, tuned for your game and fixed in concrete .
So what happens when the OS doesn't return to your process in dt time? The whole point of dt is to deal with variable framerate.
Or if you mean that you may be forced to draw at (for instance) 55fps, then the solution is to precalculate the next physics frame and linearly interpolate between the previous and next frame when drawing.
Earlier quoted context omitted.
> Drops in framerate happen. No, they don't. Game logic should run at constant 60 or more fps, even when graphics framerate is lower: http://gafferongames.com/game-physics/fix-your-timestep/ But yes, it's an interesting article, and this method allows for a bit more accuracy.
So, why is it important to have a fixed deltaTime? Except in cases where determinism really does matter. I.E. lock-step based networking. Why is this important?
And with a constant delta, if you choose it right, it can be easier to get collision detection right. You can possibly get away with checking if two things are colliding with each other right this tick instead of checking if they might have run through each other between ticks. With variable delta, if you want to get it right, you might have to check where things where half a frame ago and such, and at that point it might be easier to just check more often instead.
And I think you should probably ask the same question about variable deltaTime. Assuming that coupling rendering and game logic is not some best practice that you should default to, why would you want variable deltaTime? (There may or may not be some good answers to that, and maybe it totally depends on the game and so on.)
Can someone explain the jumping parabola graphs? I can't make sense of the description.
(Or you can pretend that the guy is moving towards the right at constant speed, and jumping, and the points in the graphs are the different positions he'll be at :)
(Edit: I'm not very sure about the pictures to the left though. Maybe higher jumps/longer time or somethingsomething.)
Earlier quoted context omitted.
Does sims 3 even have gravity?
The point being that it doesn't matter if you believe people will not play the game because game performance; if they really like it the will ignore it. And if they paid for your game you should at least try to give them an experience as good as possible.
Like, you probably would believe the amount of people playing Quake Live at 7 fps.