Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: BlakPilar on May 07, 2012, 08:02:03 pm
-
Is there a way tangent could be implemented? I've tried sin/cos, but I always get something really small, usually 0, 1, or 2 (I think). I'm making a shooter that has angled bullets for shiggles because I have nothing to do in my pre-calc class now that it's AP season (my tests are towards the end), and right now I just use a sort of slope method, but I figured it might possibly be easier/better in some way to use an angle. Then again, I've been wrong before ^^
-
Could you give us a sample please?
-
Xspeed = cos(θ) * speed
Yspeed = sin(θ) * speed
That should get the job done right?
-
Basically what I have is all of my bullets' data stored in L1, with the format being this:
Offset | Meaning
n+0 | ^r = X
n+2 | ^r = Y
n+4 | Slope
n+5 | Flag for up/down
Now, I do realize I don't need the word-sized X and Y, but I didn't feel like working with one-byte variable numbers while I was writing this. Anywho, basically what id does right now is at every update the X is incremented by 1 and if X^slope is zero, I change Y based on the flag. Right now it works fine, but my question was instead of doing a slope, would it be easier to have something like tangent be used to calculate an angle? (I just remembered it's arctan(Y/X) = angle, not the other way around >.<)
-
Instead of using slope and a flag, would it not be easier to use just an angle instead? That way you can specify the full range of directions in equal precision, and it would take up less data and use already implemented Axe commands. Your slope would range from 0 to 256, where 0 is directly to the right, 64 is directly down, 128 is directly to the left, and 192 is directly up. To extract the directions from the angle, simply use Cos(angle) for the X direction and Sin(angle) for the Y direction
-
Instead of using slope and a flag, would it not be easier to use just an angle instead?
Precisely my initial question lol. But I don't need to worry about left/right movement. The bullets start on the left side of the screen in the middle, and are fired so they go to the right either up or down.
-
Well using an angle method still works well, and if this is for some sort of shooter game, that means you can re-use some code for any bullets that are being fired back at you :D
-
Couldn't you derive it?
-
Derive what?
-
Tangent as in the trigonometric function, not the slope of a line at a point =P So, no there is nothing useful to derive here...
-
Yeah I would pretty much like a tan( function.
-
I feel like this would work:
Lbl Tan
Return sin(r1)*256//cos(r1)
-
Why *256? tan(angle) is defined as y/x, and with sin(angle) and cos(angle) being y/r and x/r respectively, tan(angle) can also be defined as sin(angle)/cos(angle), so i dont see why you would multiply sin(angle) by 256 first.
-
Why *256? tan(angle) is defined as y/x, and with sin(angle) and cos(angle) being y/r and x/r respectively, tan(angle) can also be defined as sin(angle)/cos(angle), so i dont see why you would multiply sin(angle) by 256 first.
Else you would lose precision, as the division in Axe doesn't care about the remainder. For example, 7/2=3.5 but in Axe, 7/2=3 (if you don't do floating point math of course ;))
This is also why cos and sin return between -127 and 127 because if it returned between -1 and 1, it would always be 0
-
But multiplying by 256 just changes it from something like $00A6 to $A600. It doesnt increase precision, but just changes the value. sin($A600) is completely different than sin($00A6).
-
Consider for a second the range of the tangent function. It ranges from -Infinite to +Infinite, and a large portion of the range is between -1 and 1. If we were to ignore the *256, and simply take the ratio of Sin(angle)/Cos(angle), our function would return 0 for that portion of the range, as Axe cannot represent fractional numbers. Obviously this is highly undesirable, so before we divide, we multiply by 256. This is what is known as 8.8 fixed point notation. In 8.8 fixed point, 256 is treated as 1, and this way, we can represent fractional numbers. 128 for example would represent 0.5.
-
Alright, I get it now. Thanks for the explanation. I am not used to working with platforms that do not contain easy to use floating point variables, so fixed-point and other types of arithmetic inflation are new to me.