The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
December 13, 2024, 02:20:13 pm
Home Help Search Login Register
News: Celebrating 30 years of Star Control 2 - The Ur-Quan Masters

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  General UQM Discussion (Moderator: Death 999)
| | |-+  Acceleration Governance
« previous next »
Pages: [1] Print
Author Topic: Acceleration Governance  (Read 2632 times)
Smaug
Zebranky food
*
Offline Offline

Posts: 23


I love YaBB 1G - SP1!


View Profile
Acceleration Governance
« on: April 24, 2007, 11:33:40 pm »

I have a pretty good understanding of how actual physics works, and I know a lot about how to implement it in a computer simulation. But there is a question that has boggled my mind for some time, and I'd rather not have to run through UQM's codebase to find it.

How do they make it so that the player's acceleration stops at the ships maximum velocity? See, I know enough to know it isn't a simple matter of simply capping the ship's max velocity; otherwise, gravity whips wouldn't work. And we all know that accelerating once past max velocity will accelerate the ship back towards that velocity, which likewise goes against physics.

So does anyone know what bizarre equations governs StarControl-style physics? I know it's mostly Newtonian, but I just can't seem to figure out how they governed the ship's acceleration.
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Acceleration Governance
« Reply #1 on: April 25, 2007, 01:32:42 am »

UQM has two speed maximums. The maximum that can be reached by thrust, and the maximum that can be reached by other ways (like gravity whips). In fact, thrusting when you're over the thrust-maximum will slow you down.
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
Smaug
Zebranky food
*
Offline Offline

Posts: 23


I love YaBB 1G - SP1!


View Profile
Re: Acceleration Governance
« Reply #2 on: April 25, 2007, 06:31:09 am »

I'm aware of all of that. I'm asking about the specific mechanism that governs thrust-based acceleration.

In regular physics, if you have acceleration X over time duration Y, you know that the velocity you get is X*Y + Z, where Z is the initial velocity. But in SC physics, acceleration is somehow based on both the current speed (or the ratio of the speed relative to the maximum thrust speed) and the applied acceleration. What exactly is the nature of that relationship, and what are the equations that govern it.
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Acceleration Governance
« Reply #3 on: April 25, 2007, 01:06:35 pm »

UQM uses Newtonian physics, but caps the maximum speed. Gravity whips work because the maximum speed that can be reached by gravity whips is higher than the maximum speed that can be reached by thrusting.
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
Valaggar
Guest


Email
Re: Acceleration Governance
« Reply #4 on: April 25, 2007, 02:25:02 pm »

Maybe you'll find this link interesting:
http://uqm.stack.nl/wiki/Relativity_effect
Logged
Smaug
Zebranky food
*
Offline Offline

Posts: 23


I love YaBB 1G - SP1!


View Profile
Re: Acceleration Governance
« Reply #5 on: April 25, 2007, 06:49:13 pm »

Quote
UQM uses Newtonian physics, but caps the maximum speed.

This statement, when translated to mathematics, is:

V1 = MAX(Vmax, (Athrust * t + V0) );

However, playing the game does not entirely bear this out. If this were the case, then if your velocity is over Vmax, and you press thrust at all, then your velocity will immediately drop to Vmax (or less, depending on where you're thrusting). However, if you play the game, you discover that it takes continued thrusting to go from a super-Vmax velocity to a sub-Vmax velocity. Make a gravity whip with the Umgah (high acceleration, low max-speed), and you will see how long it takes for it to slow down back to Vmax if you thrust in the direction of motion.

I could be convinced that this is how it works when the current speed is below Vmax. But not when it is above it.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Acceleration Governance
« Reply #6 on: April 25, 2007, 07:35:52 pm »

For non-Skiff vessels, src/sc2code/ship.c specifies (as far as I can tell) the following thrust behaviour (simplifying away what looks like optimisations and/or improvements to precision):

Every timestep when thrust is active, calculate a desired velocity that is the current velocity + acceleration/timestep. If the desired velocity is less than the (normal) maximum for the ship, change the current velocity to it. Simple so far.

Otherwise, check whether the ship is within range of a gravity well (i.e. planet). If it is, set the current velocity to the desired velocity if the desired velocity has smaller magnitude than the current velocity or is less than the gravity well-area maximum. In all remaining cases (including decelerating after leaving a gravity well), things get a bit complicated. The desired speed is set to the current velocity - acceleration/timestep in the reverse direction of travel (!) + half acceleration/timestep in the direction of the ship. This new velocity is applied if it decreases the speed of the ship or is below the maximum.

This seems to fit; even if thrusting in the direction of travel, the ship is slowed down.

Incidentally, the optimisations I mentioned have some interesting side effects with ships that change their maximum velocity (Torch, at least): if the ship is pointing in the same direction as it's moving at max speed, thrust has no effect. To check this out, burn the Torch afterburner in a straight line for a while, then apply normal thrust. You will find that, unexpectedly, the Torch doesn't lose speed (until you turn slightly).
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Smaug
Zebranky food
*
Offline Offline

Posts: 23


I love YaBB 1G - SP1!


View Profile
Re: Acceleration Governance
« Reply #7 on: April 26, 2007, 12:23:31 am »

That's exactly what I was looking for. Thanks!

Quote
To check this out, burn the Torch afterburner in a straight line for a while, then apply normal thrust. You will find that, unexpectedly, the Torch doesn't lose speed (until you turn slightly).

I always wondered what it was that caused that. It's funny how it was a performance optimization.

It might make an interesting patch to "restore" those optimizations to their unoptimized forms. Though the real question for that is how much it would fundamentally alter the SC physics model.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Acceleration Governance
« Reply #8 on: April 26, 2007, 08:18:56 am »

That's exactly what I was looking for. Thanks!

Quote
To check this out, burn the Torch afterburner in a straight line for a while, then apply normal thrust. You will find that, unexpectedly, the Torch doesn't lose speed (until you turn slightly).

I always wondered what it was that caused that. It's funny how it was a performance optimization.
I'm not entirely sure whether that's a performance hack, or an attempt to make sure ships max out at exactly the maximum speed (instead of maximum ± a thrust increment).

Quote
It might make an interesting patch to "restore" those optimizations to their unoptimized forms. Though the real question for that is how much it would fundamentally alter the SC physics model.
Fundamentally, not so much, if you're careful. Intuitively, it would make more sense to have thrust behave almost the same in the two situations where the travel direction is almost the same as the thrust direction and the case where it is exactly the same.

In practice, it's very hard to come out of a gravity whip travelling in exactly the same direction you're pointing. The Torch is the easiest ship to reproduce this behaviour on (I suspect the X-Former behaves similarly).
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Pages: [1] Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!