On 26-Dec-04, at 4:54 PM, Asher Dunn wrote:
On Dec 26, 2004, at 4:50 PM, Frank Condello wrote:
On 26-Dec-04, at 4:19 PM, Asher Dunn wrote:
On Dec 26, 2004, at 4:16 PM, Frank Condello wrote:
On 26-Dec-04, at 3:54 PM, Asher Dunn wrote:
On Dec 26, 2004, at 9:17 AM, Daniel Lurie wrote:
If curturn is the ship's heading then it should be:
curturn=curturn+turnrate*dt
THEN
ship.turn(curturn*dt)
So * dt in both cases?
No I'd think you'd want ship.turn(curturn)... But I also think you
haven't given us enough information. What exactly is curTurn? A
vector? A quaternion? A double (angle around the Y axis)? What does
the "ship.turn" method do? Is it cumulative? Absolute?
CurTurn is a double. Ship.Turn(curTurn) is just ship.yaw(curTurn),
but I said turn because what I typed into the email was pseudo code.
OK - but I think your approach may be flawed. When working with
time-based movement/rotations I find it's easier to think of
everything as having a specific velocity at a certain point in time
(in this case angular velocity around all three axes may make the
most sense).
That's what CurTurn is. Angular velocity around the Y axis.
You then add user input to the current velocity,
curTurn = curTurn + turnRate
subtract anti-momentum/friction (and/or add positive momentum),
and scale the result to the frame delta to get the actual
position/orientation for each frame.
ship.yaw(curTurn)
It's a little more complicated than that in code, and you'll need to
cap velocities that reach a "top speed",
if curTurn > maxTurn then curTurn = maxTurn.
but objects will automatically get smooth acceleration/deceleration
with this approach.
Isn't that what I'm doing?
Ya that looks ok - is it not working as expected? Something you may
have to do is also scale the turnRate and anti-momentum by the frame
delta. This all depends on whether your input/physics run at a fixed
frequency or every frame (there's advantages to both methods).
Once you get it working, do your self a favour and add a frame limiter
to your main loop. This way you can simulate situations where your app
might slow down. You'll also want a default frame rate cap, since
rounding errors will cause the movement to be slightly different at
different frame rates (most commercial games do this). A framerate cap
has other benefits as well, especially if you give the user some
control over the value so it can be tweaked per-system.
Frank.
------------
Open Source RB Plugins and Classes
<http://developer.chaoticbox.com>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|