Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Emerov on June 04, 2012, 09:40:29 pm
-
OK, so I have a golf-ish game where there is a ball that moves around the screen with separate x and y velocities which vary based on an angle chosen before the ball is hit. This all works perfectly fine, the ball bounces off the walls, etc. But when I try to apply friction to the ball's movement, I encounter some issues.
The process I am using to scale down my velocity vector while maintaining the same angle of motion is as follows:
1. Find the magnitude of the vector
2. Normalize the vector
3. Decrease the value of the magnitude by a friction constant
4. Multiply x and y velocity components by the new magnitude
My code looks like this:
.PUTTPUTT
P*16**cos(θ)->V //P represents power, used to determine how fast the ball will move
P*16**sin(θ)->W //V is the X-velocity; W is the Y-velocity
Repeat getKey(15)
Pt-On(X+V->X/256, Y+W->Y/256, Pic0) //X and Y are the position components
127*W//sin(tan-1(V,W))->M //M is the magnitude of the velocity vector
M-F*W//M->W //F is the friction constant. I multiply the new magnitude by each component before dividing by the current magnitude
M-F*V//M->V //because W//M would give a value of 0
If X/256>90
-V->V
End
If Y/256>59
-W->W
End
DispGraphClrDraw
End
Depending on P and θ, the code may or may not work, and I can't figure out why; the ball does seemingly random stuff, often not even going in the right direction. ???
Also, I don't know if this is relevant, but when I debugged the magnitude, it changed whenever the ball bounced off the left or right of the screen, which I don't think should be happening.
Can anybody help me fix this?
-
I took a cursory glance at your code and didn't find anything wrong with your math or concept. While there may be an issue there from your description of the problem I suspect that the main culprit here is overflow. The main computation register in Axe can only hold a value smaller than 65536 at any one time, and W^2+V^2 very likely goes over that especially if you are using x256 precision.
Maybe you can scale the x and y components by the friction constant directly instead of using the magnitude?
-
Also, make sure to add the parentheses in the square root bracket, because axe will compute it like this:
(W²+V)²
Do this instead:
W²+(V²)
-
Also, make sure to add the parentheses in the square root bracket, because axe will compute it like this:
(W²+V)²
Do this instead:
W²+(V²)
^This.
Also, make sure you used "²" which is the square operator, and not ^2 which is a modulo operator ;)
-
Also, make sure you used "²" which is the square operator, and not ^2 which is a modulo operator ;)
Oh, I totally overlooked that. :o
-
@Hayleia and MGOS: First off, I wasn't using the mod operator, but the superscript tags didn't seem to work within code tags. Also, the order of operations thing did mess up my code, but I had to scrap this line because of potential overflow.
@Squidgetx: To prevent overflow, I went ahead and used trig to find the magnitude of the vector (I do need the magnitude, because normalizing the vector to scale it should be a bit more precise than using a ratio to estimate the new component values individually).
So now the problem with the magnitude changing when the ball bounces is fixed, but the ball still moves in directions seemingly unrelated to the assigned angle of motion. I think it has to do with the lines where I scale the components (M-F*W//M->W), because when I comment them out, the code works perfectly except, of course, the ball doesn't stop. I just cannot figure out what I'm doing wrong. :P
Any more suggestions?
-
How does it move? Does the angle seem wacky right at the start or is it only when it bounces?
Edit: Also, why are you using the fixed point multiplication to assign V and W? Couldn't you just use regular multiplication and divide by 128?