Asteroids movement a SCAM! :O

[EE]

Long time no keyboard input!

Well, the title says it all... almost. :P

I've been busy trying to make a snassy top-down space shooter using the classic way of achieving asteroids movement.

Though I've realized that the "classic way" does not actually replicate pure asteroids/space movement... what's this?


When referring to the "classic way" I mean using:

Xvel = Xvel + Cos(angle)*acceleration
Yvel = Yvel - Sin(angle)*acceleration

Xpos = Xpos + Xvel
Ypos = Ypos + Yvel

X = Xpos
Y = Ypos

That's the classic answer to making asteroids movement.
Though there is a snag in that formula. It becomes very clear when using it to "travel" long distances with a capped maxvelocity.

The problem is evident in 90 degree course changes.

Example) You are moving at an angle of 90 degrees i.e up, at a velocity of 0,-100(Xvel,Yvel). You rotate your ship 90 degrees clockwise(i.e 0 degrees) and start accelerating. This results in the Xvelocity increasing to a capped 100 while maintaining Yvelocity at -100, just how we like to believe spacemovement to work(ignoring the capped speed), ending with our ship soaring steadily at 45 degrees up.

Now, say we tilt our angles with 45 degrees, starting us at an angle of 45 degrees at a velocity of 100,-100(Xvel,Yvel). Rotate 90 degrees clockwise again(to 315 degrees) and start accelerating, alas what is this!? The ship behaves more like a skidding car and will make a nice turn resulting in a velocity of 100,100(Xvel,Yvel) soaring towards an angle of 315 degrees/45 degrees down!?

How can this be?

I'll tell you, it's because of the Sin and Cos functions.

In the first example when accelerating towards the angle 0 Xvel and Yvel are both increased with our accelerating force, the Xvel is increased with the acceleration multiplied by Cos of the angle i.e
[Xvel + Cos(0)*acceleration]
Cos(0) is 1, so we get a proper acceleration towards the right.
Sin(0) is 0, so the acceleration for the Yvel is multiplied by zero, leaving our Yvel untouched.

But when tilted 45 degrees strange things happen,
Cos(315) is 0.707 and Sin(315) is -0.707 increasing our Xvel with 0.707 * acceleration and our Yvel with 0.707 * acceleration(Yvel-[-0.707]*acceleration) resulting in our 100,100 velocity!

Now, with the logic of the first example we should be moving at an angle of 0 degrees with a velocity of 100,0(Xvel,Yvel), but instead the ship behaves like if it was subject to friction.

That's the s-C-a-M!

Ok, ignoring the rant, does anyone know how the program a movement that solely behaves as either one of the examples, i.e space-ish OR frictionary(!), not combining the two depending on cardinal directions.

Sorry for the long post, I would have included an example, but just didn't, my bad. I'll try and whip one up soon so you can see what I mean.

In the meantime, feel free to help.

Cheers!
//EE

[LB]

If you use XVel and YVel instead of Angle and Velocity, then yes diagonals will be faster, as you have so clearly explained
If you want to truly maintain a speed, use Angle and Velocity rather than XVel and YVel

[EE]

Thanks, but you misunderstood. The problem is that when accelerating towards the right when travelling upwards makes you go diagonally, but when accelerating diagonally down when travelling diagonally up cancels all upward momentum making a "turn" towards diagonally down.

Do you see? Btw the Xvel and Yvel is needed to position the ship and are only a result of the angle and velocity.

Thanks though!

//EE

Edit: Here! Have a picture!

[EE]

Here's an example of a basic engine using the classic code. Try it out and you'll see what I mean.

//EE

http://www.mediafire.com/?v491hzba6dnv4eq

[MuddyMole]

It's like LB says - the problem is because you're capping X and Y velocities, and not overall speed.

You should be saying:

+ Always
-> Xvel = Xvel + Cos(angle)*acceleration
-> Yvel = Yvel - Sin(angle)*acceleration
-> MoveSpeed = sqr((Xvel pow 2)+(Yvel pow 2))

+ If MoveSpeed > MaxSpeed
-> Xvel = Xvel * MaxSpeed / MoveSpeed
-> Yvel = Yvel * MaxSpeed / MoveSpeed

+ Always
-> Xpos = Xpos + Xvel
-> Ypos = Ypos + Yvel
-> X = Xpos
-> Y = Ypos


I made a kind of Asteroids movement, but with a twist:
https://skydrive.live.com/self.aspx/Public/Spacey.mfa?cid=b1e7ee094271bbda&sc=documents
< and > control both rotation and acceleration.

[LB]

Actually, I think he may be referring to the curve...although I am not sure what he wants instead of the curve.

[Jacob]

Try Nifflas' sub pixel movement widget with collisions and remove the deceleration code; if I recall correctly it works quite well.

[EE]

It's not a speed issue, it's a curve issue. Have you tried my example? If not, try doing this:

1. At an angle of 0 degrees, accelerate to maxvelocity.

2. Without accelerating, rotate to 90 degrees and then accelerate to maxvelocity.

3. The ship should be moving diagonally up-right.


Now we are going to do the exact same thing except we start at 45 degrees.

1. At an angle of 45 degrees, accelerate to maxvelocity.

2. Without accelerating, rotate to 135 degrees and then accelerate to maxvelocity.

3. The ship will make a turn towards 135 degrees instead of moving towards the angle 90. That's the problem.

I aiming for simple space-physics, when applying forces in cardinal directions this way works just like it should. The problem is the decceleration of the perpendicular force that occurs at any other angles.


Have some amazing art:

This is the first example.
A ship(?) is travelling at maxspeed towards the right(red arrow), then it's crazy engine accelerates it upwards(green arrow). The resulting movement is indicated by the purple arrow, when the ship's engine has pressed it to an equal upward velocity as its initial right velocity it will be travelling along the diagonal. This is basic.

Now, since it is forces that moves the ship the initial angle shouldn't be of matter for the physics. This is the result we should see if it was a correct engine:


But! This is not the case. When not moving in a cardinal direction initially, the same manouver results in a decceleration of the initial force, resulting in a friction like curve towards the "green direction"


Do you understand what I'm talking about now?

I know why this happens, but not how one should build an engine for basic space physics.

Regards
//EE

Edit: Thanks for the tip about Nifflas widget! I just tried that and it seems very promising! Now to convert it from four dir input to angles..

//EE

[Fimbul]

EE, this an effect of having X and Y capped.
I mean, it works as intended in your first example because the ship is moving vertically (y speed of 100) then it moves horizontally (affecting only the X speed and not the Y speed).

The problem is that, with a 45º angle (or anything that is not a multiple of 90º), whenever you accelerate you have to change both Y and X speeds according to a ratio based on the angle the force is applied.

The problem with your code is that it is removing force from one of your vectors in order to alter the compound vector (which is a mix between X and Y force) - that's why there is no problem with straight angles/forces. I bet the problem shows up in angles other than 45º too, but to a lesser degree.

Things you could try (off the top of my head):

• Uncap X and Y virtually - that is: make them go as high as they want, but only speeds up to 100 affect the ship's movement (i.e: X can be 3845 but the actual speed is given by max(x,100) or min(x,-100) - same for y)
• Cap compound speed - in your engine, if X is 100 and Y is 100, the compound velocity of 45º is greater than 100 (it's actually 141,421 - X and Y are the catheti and the compound velocity is the hypotenuse of an imaginary triangle). If overall speed can't go above 100, you may get the effect you desire.

[EE]

Thanks for all the help everyone.

I sincerely believe that this engine(as seen in the example) is not a correct way of making 'realistic' space physics.

So if I rephrase my question;

How would you guys go about making 'realistic' space ship physics?

Thanks!
//EE