开云体育

**


One more question regarding the actual calculation.

The question that comes to mind is "what is the trigger that causes
the penguin to be rendered on the screen?" Is there some internal timer?
External timer?
In either case, if we separate the drawing trigger from the actual
drawing, then the calculation becomes.

Dt = prevTime - now()
And
X = prevX + incrementX(dt) (based on whichever factors you want to
take into account when moving, deceleration, friction, etc.).

The frame rate does not play into this calculation at all.

What am I missing?


-----Original Message-----
From: testdrivendevelopment@...
[mailto:testdrivendevelopment@...] On Behalf Of Esko
Luontola
Sent: Monday, February 18, 2013 12:10 PM
To: testdrivendevelopment@...
Subject: Re: [TDD] How do you write tests if you aren't sure what the
result should be?

Ron Jeffries wrote on 17.2.2013 13:39:

OK, well, he's moving 15 per tick. But now on the new iPad I get 60
ticks

and he should move about half that.

I should generalize this.
Hm, well, I want him to go 900 pixels in 2 seconds. That's 450
pixels per

second.

Um, maybe if I just read out the actual time since last time I can
use

that.

So I'll save time in timeThen and read time now and difference them.

If we happen to have some domain knowledge of game development and
common patterns in game design, we might decide to decouple the
physics time step from the frame rate [1] and use a fixed time step
for the physics, to keep the physics calculations deterministic. For
example the game Supreme Commander (2007) does its physics calculations at

"Take a look at the video if you haven't already. What frame rate do
you think the game is running at? The correct answer is 10 frames per

Wait, what? It looks far smoother than 10 fps you say! It is and it isn't.
The game is actually running at two separate frame rates."

To make the visuals update at a smoother pace, the game state is
interpolated to match the frame rate. There are various techniques for
interpolating/dead reckoning [3][4], but that's a whole nother story.

[1]
[2]


-tale-
of-desyncs/
[3]


ng_for
_.php
[4]


ork-pr
ogramming/targeting-a-variation-of-dead-reckoning-r1370

--
Esko Luontola
www.orfjackal.net

------------------------------------

Yahoo! Groups Links

OK, well, he's moving 15 per tick. But now on the new iPad I get 60 ticks

I should generalize this.
Hm, well, I want him to go 900 pixels in 2 seconds. That's 450 pixels per

Um, maybe if I just read out the actual time since last time I can use

So I'll save time in timeThen and read time now and difference them.

Hi Amir,

On Feb 17, 2013, at 11:00 PM, "Amir Kolsky" <kolsky@...> wrote:

I meant that the derivation of the formulae that you THEN implemented in

TDD

did not have anything to do with TDD.

Of course it didn't have to do with TDD. It has to do with the laws of
physics. It has to do with understanding the problem and is possible
solutions. It has to do with understanding what happens if frame rate
changes.

If we don't understand those things, our penguin will never fly right,
because there are an infinity of possible calculations for his x position
and y position.

These are matters for thought. When we do TDD we don't stop thinking. We
stop believing everything we think, and we stop imagining that when we
write code, it works as we imagine.

Ron Jeffries
www.XProgramming.com
If another does not intend offense, it is wrong for me to seek it;
if another does indeed intend offense, it is foolish for me to permit it.
-- Kelly Easterley







------------------------------------

Yahoo! Groups Links

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.

**


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

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

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

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

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

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

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

Hi Avi 鈥�

On Feb 17, 2013, at 1:03 AM, Avi Kessner <akessner@...> wrote:

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.

I was supposing that dt is some kind of a time value. I imagined that it meant "delta time" or "change in time since last time". Its dimensions must surely be "seconds" or some other time value. I don't know whether you have set

I was supposing that x is some kind of position value. I imagined that its dimensions were "meters" or "pixels", or some other distance value.

The expression was x += dt. Dimensionally, pixels += seconds, or meters += seconds. Can't really be right.

Now what we often do when we animate a penguin -- I mean who doesn't animate a penguin every now and again -- is reason as follows:

I suppose I'll get about 30 frames a second;
I suppose I'd like him to move across the screen in about 2 seconds;
The way gravity works is you go constant speed in X but up and down in Y;
I plan to get 30 frames a second;
So I'll need 60 frames to move him
The part of the screen he'll move across is about 900 pixels;
He has to move 900/60 鈥� uh 鈥� 15 pixels every second in the x direction;
鈥� and so on

Then, having done the math, when we calculate the penguin's x in our draw() code, called, we guess, every 1/30 second, we can just write:

x += 15

Then the new iPad comes out and our draw() function is called 60 times a second and poor Pengi zips across so fast that it's no fun. So we reason:

OK, well, he's moving 15 per tick. But now on the new iPad I get 60 ticks and he should move about half that.
I should generalize this.
Hm, well, I want him to go 900 pixels in 2 seconds. That's 450 pixels per second.
Um, maybe if I just read out the actual time since last time I can use that.
So I'll save time in timeThen and read time now and difference them.
the time() function is a float, seconds since long time ago.

And we write

draw()
timeNow = time()
dt = timeNow - timeThen
x += 450*dt
timeThen = timeNow
end

Now our draw() function is independent of frame rate. But wait! what is that 450*dt??? It seems we just added time to distance and that's supposed to be wrong. It's ok. look at the dimensional analysis of that statement:

pixels += (pixels/second)*second

the seconds cancel and we're adding pixels to pixels
if x was in meters, it'd be meters += (meters/second)*second, so that would be OK too.

Now our question here is how to TDD all this. I would do at least this much thinking with pencil and paper, which takes less time than it took to write this. To TDD the patch of code above, I've got a problem, which is that it calls time(). I can't really TDD well that way, because time is always weird. Just as we do with a random number, we need to abstract time out, so that our test can look like this:

deltaTime = 1.0/30.0
assertEquals(15, distanceMoved(deltaTime))

This requires us to write

distanceMoved(float dt)
return 450*dt
end

which means our draw function needs to be

draw()
timeNow = time()
dt = timeNow-timeThen
x += distanceMoved(dt)
timeThen = timeNow
end

Now how might we TDD that whole patch. Honestly unless I was demonstrating my great TDD powers, I'm not sure I would, but your mission is to demonstrate great TDD powers. It's darned hard to do in retrospect, when the code is so easy, but we have to learn to think backwards, so let's pretend that we are thinking that the draw has to look like that but that we were being really retentive about TDD, and didn't type it in yet. So we reason, knowing full well what we want:

OK, we have a way to compute distanceMoved as a function of a delta-time.
Now we need a way to measure delta time.
So, um, let's have a delta-time function that we call in our draw. Its test is, um 鈥�

beginTime = 1.5
initDeltaTime(beginTime)
endTime = 2
assertEquals(0.5, deltaTime(endTime))
endTime = 3.5
assertEquals(1.5, deltaTime(endTime))

Hmm, how can we write delta time? Well 鈥�

lastTime = 0.0
initDeltaTime(float aTime)
lastTime = aTime
end

float deltaTime(float aTime)
dt = aTime-lastTime
lastTime = atime
return dt
end

Now the draw() that we have in our head looks like
x += distanceMoved(deltaTime(time())
y += godWhatWillWeDoAboutY(time())
sprite("penguin", x, y)

and both the distanceMoved function and the deltaTime function have been fully TDD'd. Now we do the y function.
Because we've read that article that you posted, we realize that we want a velocity that isn't constant 450/second, but is instead a function of gravity. And we know that we want to do that average velocity trick -- after we understand it, which we might not at the beginning.

We proceed similarly. Your mission, if you care to, is to follow my reasoning above, then try to reason similarly as you calculate Y. I don't know yet what I'd do, because I'm stopping here for now. Unless I decide to animate a penguin in Codea 鈥�

Hang in there!

Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?
-- Ronald Reagan





[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

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

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

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

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

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

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

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