Possible inconsistencies with physics (collision with track)

[tigrouind]

It's not clear if the original physics logic is still in place.
First part is the original (from PSX version) second part is the rewrite.
All those 3 examples are the same thing : adding a vector to velocity, but they seems to do it differently (while original do it same way)

Example 1

//DYNAM.C > shipTrkReaction()
playerShip->vpivot.vx += (facePtr->normal.vx*60)/50;		 
playerShip->vpivot.vy += (facePtr->normal.vy*60)/50;
playerShip->vpivot.vz += (facePtr->normal.vz*60)/50;

The normal vector is simply added as it is (similar to original code)

//ship_player.c > ship_player_update_race()
self->velocity = vec3_add(self->velocity, face->normal);

Example 2

//Collide.c > WingCollision() 
playerShip->vpivot.vx += facePtr->normal.vx;		 
playerShip->vpivot.vy += facePtr->normal.vy;
playerShip->vpivot.vz += facePtr->normal.vz;

The normal vector is multiplied by 4096.

//ship.c > ship_resolve_wing_collision()
self->velocity = vec3_add(self->velocity, vec3_mulf(face->normal, 4096)); 

Example 3

//DYNAM.C > shipTrkReaction()
playerShip->vpivot.vx += ((playerShip->nearTrkSect->nextSection.ptr->centre.vx - playerShip->nearTrkSect->centre.vx)*60)/50;
playerShip->vpivot.vy += ((playerShip->nearTrkSect->nextSection.ptr->centre.vy - playerShip->nearTrkSect->centre.vy)*60)/50;
playerShip->vpivot.vz += ((playerShip->nearTrkSect->nextSection.ptr->centre.vz - playerShip->nearTrkSect->centre.vz)*60)/50;

The vector is multiplied by 30 * system_tick()

//ship_player.c > ship_player_update_race()
vec3_t track_direction = vec3_sub(self->section->next->center, self->section->center);
self->velocity = vec3_add(self->velocity, vec3_mulf(track_direction, 30 * system_tick()));

[Dominic Szablewski]

Just thinking out loud: I believe 2 and 3 are correct, but 1 might not be!? In the original the face normal is in .12 fixed point, so 4096 corresponds to 1.0 floating point. Also, all physics calculations in the original run at 30 fps.

In 2, we get a singular impulse from the collision. It's added just once to the velociy. No need to adjust for frame time.

In 3, we get a continuous acceleration from the boost pad. The longer we stay on the boost pad, the greater the resulting velocity, so we need to account for frame time. Otherwise we'd add more acceleration when we have more frames on the boost.

In 1, we should account for frame time and also multiply the normal by 4096. We're not doing either.

As stated in my blog post, I'm not sure if the variable physics update were a good idea in general. Maybe we should just run physics at a fixed 120 fps (or another multiple of the original 30) and interpolate for rendering. Just updating at the original 30 fps will make the controls less responsive. I lack experience here. How to other racing games do this?