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

You are correct, you multiply the velocity by the dt not add. Another
change I'll have to make to this old system :)

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


On Sun, Feb 17, 2013 at 8:03 AM, Avi Kessner <[email protected]> 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.
> On Feb 17, 2013 3:46 AM, "Amir Kolsky" <[email protected]> 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: [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
>>
>>  
>>
>


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