Ok, I know that each machine runs at different speeds and will even process the exact same computations within the same machine within different amounts of time. This presents a problem if I want to have smooth (and consistent) movement. Here is how I have been doing it:

void Camera::UpdateTBF(){
	newTime=clock();
fTBF=double(newTime-oldTime);

	oldTime=newTime;
	tbfFactor=fTBF/1000.0;

}

fTBF and tbfFactor are both doubles. newTime and oldTime are longs.

Whenever movement occurs, the amount of movement is multiplied by tbfFactor.

I thought this would work great, but every so often I see "jumps" in movement. So I arbitrarily set tbfFactor to 0.015 (that's about the average for my machine) and I get smooth, consistent movement all the time. What's the deal? I MUST be doing it wrong.....

The de facto answer seems to be

Game Loop

and

Fix Your Timestep

Everyone should be forced to read both of those!

Also, L.Spiro's Fixed Timestep Implementation

Also, L.Spiro's Fixed Timestep Implementation

This is something I should have STARTED my project with..... It may be too difficult to implement without starting fresh. Here is what I get from the article:

-Update the render each frame

-All movement is 33.3ms behind what is actually rendered

-Only do ACTUAL movement every 33.3ms

-For every frame between the 33.3, interpolate the matrix of EACH object rendered from an "old state" to a "new state"

Is that about right?

If so, I may have a problem (maybe). I have certain instances where the player's ship is moving at 'relativistic' speeds and therefore from one frame to the next, objects could be moving (relative to the player) at millions of meters per frame. If the update happens every 33.3ms, then the actual distance traveled can be up to 33.3 times what it would be each frame. I could pass right through a planet without a scratch and the physics wouldn't know the difference....... There are ways around this problem, but that pulls me deeper down the rabbit hole.