Re: 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

<*> 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/