I may be missing something about this whole discussion, but isn't the dt
part supposed to take care of the delta in time? I.e., the variation should
be in that, rather than in some factor.
toggle quoted message
Show quoted text
-----Original Message----- From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Edwin Castro Sent: Saturday, February 16, 2013 2:59 PM To: Test Driven Development Subject: Re: [TDD] How do you write tests if you aren't sure what the result should be? let f = new framerate let g = old framerate x += dt*(g/f) + f*v f = 32 and g = 30 gives me g/f = 30/32 = 0.9375 On Sat, Feb 16, 2013 at 11:54 AM, Edwin Castro <egcastr@...> wrote: Actually, this reminds me of my microcontrollers course back in
college where we had to bridge between two different sampling rates...
In that course we had to actually use three different sampling rates
so that we could control the two we really cared about. Of course,
that was 13+ years ago so I don't have anything more concrete than that.
I would find out where the 0.937 factor comes from because I would not
expect it to be there... unless your calculations are based on the
fact that in the previous frame the framerate was 30 and now it is 32
which implies you can calculate the factor by knowing the old and new framerates.
On Sat, Feb 16, 2013 at 11:51 AM, Edwin Castro <egcastr@...> wrote:
I would expect that the 0.937 factor is a calculated factor that
somehow incorporates the fact that you are comparing framerates of 30 and
32 fps... In other words, your calculations are relativistic and you are trying
to use classical equations.
On Sat, Feb 16, 2013 at 11:47 AM, Avi Kessner <akessner@...> wrote:
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 - 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 - 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
------------------------------------
Yahoo! Groups Links
--
Edwin G. Castro
--
Edwin G. Castro
-- Edwin G. Castro ------------------------------------ Yahoo! Groups Links
|
