[aldo_14]

Um.... i'm looking for a quick & simple momentum equation for 2D to simulate deceleration over time (it's for a sort of R-type sort of game I'm writing)

At moment my best guess is something like

Code: [Select]


(pseudo)
/**
* Use something to stop acceleration / decelleration overlapping
**/
protected Object synch = new Object();

/**
*  code that's called on a regular & guaranteed interval
**/
public void acceleration()  {
synchronized(synch)  { //or some semaphore pish
  nextTranslation = new IntPoint(currentTranslation.x() * DECLINING_FACTOR, currentTranslation.y() * DECLINING_FACTOR);
 [b]//this is where some decellerating momentum calculation comes in[/b]
}
}

/**
* On keypress
**/
public void thrust(int x, int y)  {
synchronized(synch)  {
  nextTranslation = new IntPoint(currentTranslation.x() * x, currentTranslation.y() * y, );[b]
//and this is where acceration comes in[/b]
}
}



I was previously planning on using a sort of jump x co-ords on keypress system, but I think this would be better.  I don't know physics, though

[Flaser]

The main problem with this sort of program is writting the routine that will make the transition smooth.

You can't directly tie in the x,y pixel position into the formulae. (If you do, the movement will be stutterish - the drawn pixels will jump instead a seamless translation.)

IMHO you should make a time based formulae and then make a function that outputs the current x,y pixel positions to draw.

(For 2D, 2 perpendicular accelerations will do. Since we're already using them, let them be x and y.
All posible 2D accelerations can be modeled as the sum of an x and y axis acceleration.)

The unit of acceleration should be pixel/second^2 while velocity should be pixel/second.
You *will* be using fraction values.
You should store the real position and the drawn position. The later will be made by converting the real pos. into an integer value
That way:
// (r - for real) r.pos is a record with two float values: x and y
// (d - for drawn) d.pos is also a record with two integers: x and y
// t is a time function that outputs time in seconds, if you have a function that outputs time in ms (milliseconds) than divide the value by 1000.

r.pos.x = r.pos.x + (vel.x * t) + (a.x/2*t*t)
r.pos.y = r.pos.y + (vel.y * t) + (a.y/2*t*t)
vel.x = vel.x + (a.x * t)
vel.y = vel.y + (a.y *t)

//These funtions handle the change of position
//vel holds the x,y velocity values
//a holds the x,y acceleration values

d.pos.x = cint(r.pos.x)
d.pos.y = cint(r.pos.y)

When the a.x, a.y values are not 0 the object will either accelerate of decelerate. You don't need a separate fucntion for either one.
If a.x * vel.x > 0 then it's accelerating on the x axis
If a.x * vel.y < 0 then it's decelerating on the x axis
If a.x * vel.y = 0 then it's either moving steadly (acceleration = 0) or the object has momentarily stopped on the screen (vel = 0)

[aldo_14]

The x,y position is within an abstract world; the actual drawing translates that to whatever the current resolution (etc) is; I'm abstracting out graphics (in particular) for future additions to that particular area.  The movement calculations and graphics updatery will be in seperate threads, although I may use observer updating if it's more efficient...  either way, I have plans for ensuring smoothness.

The different acceleration/decelleration bits are to divide up the control; decelleration is automatic (i.e. would have been scheduled at regular intervals), acceleration is manual (i.e. you lose speed naturally, but can thrust to compensate).

I think I can use those formulae, cheers.   Not sure which paradigm to use time within; my intention is to abstract any connection between graphics (and sound) and the 'world' out, so there'd be close to real time scheduled updating of the position, etc (i.e. at a higher rate than drawing).

[Bobboau]

Java?

what you want is a speed, coords/sec, positive generaly being up/right, negitive being down/left (for y/x) you add a speed value to the object that is to be moveing, then simply get the time it's been sence the last time you've been through the loop (in seconds) and multiply the speed in both the x and y directions by this time, add the result to the object position.

so to make things simple

pos=speed*time

now this isn't momentum, if you are going to be doing colisions and needing momentum, it gets a bit more complicated.

[aldo_14]

(Yes.  Java with JOGL for the graphics to be precise.  Could convert all or parts to C++ if I get it working.... maybe)

I want... player can alter x or y by thrusting with cursors, etc (might add direct draggable mouse control instead,  I'm not sure), but your speed decreases over time.  So rather than tap up = move up x spaces, tap up means upward velocity increases by x or something (which reminds me, that top pseudocode is complete bollocks for speeds of 0).

I've not decided on collisions, yet.  Although I think it'd be trivial to actually handle them (in a very basic sense, by fiddling with the colliding entities vectors) because I'm only using a rectangular bounding box rather than per-pixel (albeit I think there's library support for an n-gon... thank god java has stuff for detecting intersection, because I can't be bothered with that sort of trivial stuff ).