RE: How do you write tests if you aren't sure what the result should be?

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: [email protected]
[mailto:[email protected]] 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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:
>>> http://gafferongames.com/game-physics/fix-your-timestep/
>>> >>>
>>> >>> Best,
>>> >>> Stefan
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> Am 16.02.2013 17:49, schrieb Avi Kessner:
>>> >>>> Yes, the code is the same.
>>> >>>>
>>> >>>> See
>>> >>>> http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html  from
>>> >>>> http://news.ycombinator.com/item?id=4934855
>>> >>>>     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
>>> >>>> <[email protected]>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 <[email protected]> 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 <[email protected]> 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:
>>> http://gafferongames.com/game-physics/fix-your-timestep/
>>> >>>
>>> >>> Best,
>>> >>> Stefan
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> Am 16.02.2013 17:49, schrieb Avi Kessner:
>>> >>>> Yes, the code is the same.
>>> >>>>
>>> >>>> See
>>> >>>> http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html  from
>>> >>>> http://news.ycombinator.com/item?id=4934855
>>> >>>>     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
>>> >>>> <[email protected]>wrote:
>>> >>>>
>>> >>>
>>> >>>
>>> >>> ------------------------------------
>>> >>>
>>> >>> Yahoo! Groups Links
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >> ------------------------------------
>>> >>
>>> >> Yahoo! Groups Links
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > ------------------------------------
>>> >
>>> > Yahoo! Groups Links
>>> >
>>> >
>>> >
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Edwin G. Castro
>>
>
>
>
> --
> Edwin G. Castro
>



-- 
Edwin G. Castro


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



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

Yahoo! Groups Links





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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/