In the case of a flying penguin it doesn't work.
The basic formula for the penguin flying through the air is x += dt + v
If this is calculated 30 times per second you basically get x += dt +
30v, but if you calculate it 32 times per second, you get x +=
(dt*0.937) + 32v
And in reality, you get a range of say 28-34 fps with it changing every frame.
That's why I thought it was a sort of heisenberg problem. I can
either fix the time it takes, or I can fix the distance it goes, but I
can't have both be variable. Using the idea that "The renderer
produces time and the simulation consumes it in discrete dt sized
chunks." seems like it will solve the problem, because I can then
right tests for different amounts of times produced and consumed and
make sure they are equal.
brought to you by the letters A, V, and I
and the number 47
On Sat, Feb 16, 2013 at 9:27 PM, sh <shvfn@...> wrote:
Avi,
the first option should work. When your test is ok for 30 fps, you can
safely assume that it will work for higher framerates.
Best,
Stefan
Am 16.02.2013 20:07, schrieb Avi Kessner:
The first option won't work, because a 30 to 60 fps has to be assumed.
That second option might be what is needed however. However, not the
fixed time step but rather the "
Free the physics" section. "So what we want is the best of both
worlds: a fixed delta time value for the simulation plus the ability
to render at different framerates. These two things seem completely at
odds, and they are ¨C unless we can find a way to decouple the
simulation and rendering framerates."
brought to you by the letters A, V, and I
and the number 47
On Sat, Feb 16, 2013 at 7:58 PM, sh <shvfn@...> wrote:
I don't think this is very heisenbergish... :)
The first option is to assume a sensible minimum framerate (perhaps 30
FPS) and make that a specification for your game. (With 10 FPS it
probably won't be fun anyway.)
Then make the framerate a variable in your tests: physics.update(
variableTimestepInMilliseconds );
This makes the code testable for a given framerate. Of course higher
framerates will deliver a small variation in the calculations, but that
shouldn't mess up the behaviour of the engine.
The second option is a fixed timestep for your physics calculations as
is described here:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
for another example, where how accurate your timer or framerate is can
affect the results of the tests.
In the gravity example, if I run the equation as if the user has 10 frames
per second, I will get different results than if they run at 60 frames per
second.
Granted this is partially a problem with the code, but it should still be
testable.
Perhaps this is the Heisenberg of unit testing?
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 10:40 PM, George Dinwiddie
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
brought to you by the letters A, V, and I
and the number 47
On Sat, Feb 16, 2013 at 9:27 PM, sh <shvfn@...> wrote:
Avi,
the first option should work. When your test is ok for 30 fps, you can
safely assume that it will work for higher framerates.
Best,
Stefan
Am 16.02.2013 20:07, schrieb Avi Kessner:
The first option won't work, because a 30 to 60 fps has to be assumed.
That second option might be what is needed however. However, not the
fixed time step but rather the "
Free the physics" section. "So what we want is the best of both
worlds: a fixed delta time value for the simulation plus the ability
to render at different framerates. These two things seem completely at
odds, and they are ¨C unless we can find a way to decouple the
simulation and rendering framerates."
brought to you by the letters A, V, and I
and the number 47
On Sat, Feb 16, 2013 at 7:58 PM, sh <shvfn@...> wrote:
I don't think this is very heisenbergish... :)
The first option is to assume a sensible minimum framerate (perhaps 30
FPS) and make that a specification for your game. (With 10 FPS it
probably won't be fun anyway.)
Then make the framerate a variable in your tests: physics.update(
variableTimestepInMilliseconds );
This makes the code testable for a given framerate. Of course higher
framerates will deliver a small variation in the calculations, but that
shouldn't mess up the behaviour of the engine.
The second option is a fixed timestep for your physics calculations as
is described here:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
for another example, where how accurate your timer or framerate is can
affect the results of the tests.
In the gravity example, if I run the equation as if the user has 10 frames
per second, I will get different results than if they run at 60 frames per
second.
Granted this is partially a problem with the code, but it should still be
testable.
Perhaps this is the Heisenberg of unit testing?
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 10:40 PM, George Dinwiddie
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
