1. use a force and a mass on your spaceship. Say like force 10, mass 2 => accel 10/2 =5 or with the same force but with a bigger mass like 5 you only get accelation to 2. The bigger the ship the slower the acceleration.

2.
speed = speed + (delta t) * acceleration

this seems correct. Do you remember that accelaration and speed is a vector. And did you also do position = position + speed * (delta t) to get the new position. Position is also a vector.

Quote:Original post by kylecrass
I thought i would do this:

speed = speed + (delta t) * acceleration

but that does not seem to work...am i missing something?

This would work all right (assuming of course you're doing the same to find position from speed, as Zyberant suggested), it is -in fact- numerical integration, but this one (euler's method) is prone to some problems and it's not that accurate for more advanced simulations.

Make sure to use a constant, small enough timestep. Else you'll get jittering objects and the time will not be uniform... I suggest you do sth like this:

void SimulationHeartBeat()
{

  1. const float dt = 1.f/60.f; (max)  2. unprocessed_time += (time - last_update_time);  3. while( unprocessed_time > dt )  {    4. update_simulation_objects();        5. unprocessed_time -= dt;  }  6. last_update_time = time;}

This will make sure that the required number of simulations will have been performed, anytime...

Well, to start with theory, Euler's method is a 2nd order method while the spcific RK is 4th order. This means that the cutoff error from the entire Taylor expansion is -in 1st case- of the order of magintude of dt3, while in the RK it reduces to order of dt5. (!)

Euler's method introduces severe errors especially with integrands that have quite large (and quite often) maximum values of second derivative (like stiff spring forces). This quantity can be considered a measure of how fast the rate of change of the integrand is, and affects immediately the stability of Euler's method since it controls how much of the function's curve may end up completely missed/ignored by the method...

However, don't rush to deem it useless. Considering the CPU overhead in both cases, many would opt for Euler instead, especially in games where maximum possible precision isn't *that* necessary...

f(x) = xi + vi * (x) + [a * (x)²] / 2
f(x) = xi + vi * (x) + [a * (x)²] / 2 + [j * (x)³] / 6

isn't it f(t). t instead of x. You use time to get the position.

Also this is the exact method. Given some start condition and the time, you get the exact position. The delta time is another method.

If the start condition change with the time then i don't think you can use the exact method then. This is where the delta time method come in.

@Kylecrass
If you've figured out an (independent) way to calculate the derivative of the acceleration, and then calculate all other quantities (acceleration, velocity, position) from it, then theoretically, yes, you would have better accuracy. You would have limited the cutoff error by a whole order of magnitude!
This is theoretical though; I don't know whether the extra integration will cost any precision loss, but it should be better.
Notice though, that you'll have to come up with a way to calculate the derivative of acceleration first.
I mean, don't do something like that: (It's not gonna make a difference!)

1. prevAcc = a;2. a = (total F)/mass;3. v+= a*dt;4. x += v*dt + (1/2)*a*dt2 + (1/6)*((a-prevAcc)/dt)*dt3

@Zyberant

Quote:
isn't it f(t). t instead of x. You use time to get the position.

Also this is the exact method. Given some start condition and the time, you get the exact position. The delta time is another method

You can use anything to get position, so long as it is expressed with respect to that quantity. Of course, its derivatives wouldn't be -then- velocity and acceleration, but it is perfectly legal...
The Taylor series expansion of a function, around any point x0 of its domain, is:
f(x) = f(x0) + (x-x0)*f'(x0) + (x-x0)2*f"(x0)/2 + ... + (x-x0)n*f(n)(x0)/n!

If "x" was time "t" instead, then substituting t=t0+dt in the formula, yields:
f(t0+dt) = f(t0) + dt*f'(t0) + dt2*f"(t0)/2 + dt3*f(3)(t0)/3! + ...

Therefore, the "dt" formula is the very same thing.
(You meant this one, didn't you?)

Quote:
This method should theoretically give me better precision?

I really doubt you can tweak the Euler method to get any better precision. The only way is to decrease the timestep, and it doesn't come cheap.

If you really need precision, I suggest you should turn to another integration method like Verlet or RK4, especially if you'll be dealing with springs and constraints.
Verlet is still 2nd order, however it calculates position without using any velocity, thus restricting the error to a minimum. Constraints are also very easy to implement with verlet.

RK on the other hand, is far more accurate, because it uses an estimated "average" value of the derivative throught the timestep, but be prepared to pay the price in cpu overhead.