开云体育

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

Once we have separated the rendering from the time keeper, you are correct.
However, previously we(I?) was using "frame rate" as a simple term to refer
to how often the function gets called. (Before it was recognized that
rendering and timers can be separated)

brought to you by the letters A, V, and I and the number 47


On Mon, Feb 18, 2013 at 10:26 PM, Amir Kolsky <kolsky@...> wrote:

**


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

10 fps, as said in [2]:

"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

second.

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

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



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

Yahoo! Groups Links