OK, that makes it even simpler.
This is where TDD can tell you whether you've reached your final destination
or not. You can calculate the exact point where the penguin should stop "in
the real world", and then specify what the allowed error is.
At this point you need to refine your algorithm, taking into account things
like the current framework, current location, elapsed time, etc. until the
test passes.
A.
toggle quoted message
Show quoted text
-----Original Message----- From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Avi Kessner Sent: Sunday, February 17, 2013 1:03 AM To: testdrivendevelopment@... Subject: RE: [TDD] How do you write tests if you aren't sure what the result should be? My comparison was supposed to be regarding the culmative calculation, not the per tick calculation. Ill have to look up when velocity is multiplied vs when it's added. On Feb 17, 2013 3:46 AM, "Amir Kolsky" <kolsky@...> wrote: **
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.
-----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
------------------------------------ Yahoo! Groups Links
|
