Fixing gravity/acceleration

[mankrip]

This article seems to describe a bug in the way Quake calculates gravity and acceleration in general.

After looking into SV_AddGravity, it seems Quake really has this problem:

Code: Select all

ent->v.velocity[2] -= ent_gravity * sv_gravity.value * host_frametime;

Has anyone already implemented a solution for this?

[leileilol]

It's not a bug, it's a "feature"! "Fix" this and you will recieve essays of whining on how you suck, brought to you by the Picmip 256 Fov 150 Fullbright Association of Europe.

Wazat's probably said enough what i'd want to say in another thread somewhere, i'm just giving the most abridged version I can.

I do wonder what mods this could break with. Quake Rally?

[mankrip]

The only mods that could have problems when fixing this are the ones that doesn't behave correctly in high framerates, and I never found any mod like this.

On the other hand, fixing this would probably improve the gameplay of several mods that behaves incorrectly at low framerates.

[r00k]

This would be a unique algorithm for Quake, changing this would change the way the game feels, thus breaking gameplay-compatibility.
If your would mod benefits more by 'fixing' this, then just create a switch.

[Lardarse]

...why is it wrong? What "should" it be?

[mankrip]

This would be a unique algorithm for Quake, changing this would change the way the game feels

It wouldn't. All this change would do is make the gameplay in slow computers behave like the gameplay in fast ones. All engines already works like this when running at 60 fps:

People with fast computers would see no difference:


I'll try to implement this and do some tests.

[mh]

It's server-side anyway, so it wouldn't affect multiplayer games. I see no problem in fixing it - the very worst you can do is allow people who have low framerates to make jumps that they could have previously only made if they hadn't.

Incidentally - and slightly less important but good to know nonetheless - this also explains why particle velocities are framerate-dependent, as they go through a similar equation.

I'm going to implement this later on today and see how things turn out.

[Urre]

Twig fixed this

[mh]

This seems to work:

Code: Select all

void SV_AddGravity (edict_t *ent)
{
   float   ent_gravity;
   eval_t   *val;

   val = GetEdictFieldValue (ent, "gravity");

   if (val && val->_float)
      ent_gravity = val->_float;
   else ent_gravity = 1.0;

   // in case SV_AddGravity gets called on an entity more than once per frame
   // (can this ever happen???)
   if (ent->grav_frame != host_framecount)
   {
      // update from last frame's gravity
      ent->v.velocity[2] -= ent->last_grav;
      ent->grav_frame = host_framecount;
   }

   // evaluate this frame's gravity
   ent->last_grav = (ent_gravity * sv_gravity.value * host_frametime) / 2.0f;

   // update from this frame's gravity
   ent->v.velocity[2] -= ent->last_grav;
}

There are there obvious new fields there that need to be added to edict_t, and there is probably a bit of work required elsewhere (setting last_grav to 0 in ED_Alloc for example), but overall yes, it does let you jump much the same distance when you're running at 3 FPS.

[Sajt]

Darkplaces fixed this a long time ago. I don't remember if it was made into a sv_gameplayfix cvar, but it should be.

[mh]

I'd vote for always on. To be honest I'm having a really difficult time thinking of any advatages to not doing it. A listen server running a complex map on a slow machine is the only situation where somebody may not want it.

[Spike]

tbh, prediction is the only reason I can think of.

[metlslime]

the alternative is a fixed server FPS independent of client framerate. If client is running slow, do multiple server frames in a row. If client is running fast, skip server frame. Of course i've never done this so i'm sure there are details to work out.

The fix in the original post seems reasonable though, but i haven't looked at it closely.

[mh]

Running the server in it's own thread would be the correct solution IMO, but there are data sharing issues to be resolved (the server would need to load it's own copy of the models for starters, as these are shared by a client and a server on the same machine) and thread sync issues during network communications (even if it's just using the net_loop driver).

I've just run through most of e1 using the code I posted and it seems solid enough there. No idea what it would be like in The Real World though...

[metlslime]

the client and server only need readonly access to the shared model data once it's loaded, right? So they probably don't need their own copies of it.