Re: TIB: Gee, It's quiet here


[Prev][Next][Index][Thread]

Re: TIB: Gee, It's quiet here




Tavis Segura wrote:
> 
> >> fire.85p - a test on various methods for modeling projectile motion
> >>             (none involving changing the terrain into an array)
> >
> >I'm curious what you meant about "changing the terrain into an
> >array".  When I made my Tank Wars the terrain was created at the
> >beginning of the game, but it wasn't recorded in any way. Rather, it
> >was created by simply running a loop - For(X,0,94 - and drawing a
> >line - Line(X,0,X, (whatever). The "whatever" was picked based on the
> >position of the previous line - it was either picked to be one
> >y-coordinate below, equal to, or above the previous. Just what is it
> >that you stored into an array?
> >
> >Jody Snider
> >jody1@alaska.net
> 
> I used a sinusoidal function; in the program itself, the exact function
> I used was
> 
> AB=10cos (.1x)+10
> 
> It is a rather simple function compared to the one used in Aim, but for
> my testing, I did not need anything random, just something reasonable.
> Lists are faster since you do not have to calculate AB(x) every time you
> test for collision with the ground but just read the number in the list.
> The TI-92 version stores data calculated from a function to a list
> before drawing the terrain.
> 
> In case you are curious about the current formula:
> 
> r(x,c)=c[1]*sin(c[2]*x)+c[3]*cos(c[4]*x)+c[1]+c[3]
> 
> where a constant list c equals
>     {h^2+rand(h),
>      \pi\ *(rand()+k)/(8*k^3),
>      h^2+rand(h)+5,
>      \pi\ *(rand()+k)/(4*k^3)}
> 
> (\pi\ indicates the symbol pi)
> 
> and h and k are integers satisfying 1<=h<=4 and 1<=k<=4
>  (They determine the height and width of the sine function.)
> 
> See why I decided to use an array?  Then again, the function could use
> some simplification.  Any ideas?
> 
> Tavis
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

Yuck! That equation looks like a headache. In my game I calculated the 
next point that would be turned on, and then did a pixel-test to see 
if the point was already on. I though about have a list that had 94 
elements (one for the height of the terrain at each X value), but it 
seemed like a waste of space. The test would have had to be if 
y<=L1(x)). There didn't, and still doesn't, seem any benefit to having 
the extra list. Again, why not just use the pixel-test?

Jody Snider
jody1@alaska.net


References: