View previous topic :: View next topic |
Author |
Message |
mk

Joined: 04 Jul 2008 Posts: 94
|
Posted: Tue Apr 13, 2010 12:01 am Post subject: Fixing gravity/acceleration |
|
|
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: | ent->v.velocity[2] -= ent_gravity * sv_gravity.value * host_frametime; |
Has anyone already implemented a solution for this? _________________ Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
Back to top |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Tue Apr 13, 2010 12:28 am Post subject: |
|
|
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? _________________
 |
|
Back to top |
|
 |
mk

Joined: 04 Jul 2008 Posts: 94
|
Posted: Tue Apr 13, 2010 1:40 am Post subject: |
|
|
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. _________________ Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Apr 13, 2010 3:56 am Post subject: |
|
|
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. |
|
Back to top |
|
 |
Lardarse

Joined: 05 Nov 2005 Posts: 243 Location: Bristol, UK
|
Posted: Tue Apr 13, 2010 7:03 am Post subject: |
|
|
...why is it wrong? What "should" it be? _________________ <ekiM> Son, you're writing data structures your CPU can't cache. |
|
Back to top |
|
 |
mk

Joined: 04 Jul 2008 Posts: 94
|
Posted: Tue Apr 13, 2010 7:16 am Post subject: |
|
|
r00k wrote: | 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. _________________ Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Tue Apr 13, 2010 9:04 am Post subject: |
|
|
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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Tue Apr 13, 2010 11:54 am Post subject: |
|
|
Twig fixed this  _________________ Look out for Twigboy |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Tue Apr 13, 2010 1:10 pm Post subject: |
|
|
This seems to work: Code: | 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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Tue Apr 13, 2010 5:44 pm Post subject: |
|
|
Darkplaces fixed this a long time ago. I don't remember if it was made into a sv_gameplayfix cvar, but it should be. _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Tue Apr 13, 2010 9:23 pm Post subject: |
|
|
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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Apr 13, 2010 9:40 pm Post subject: |
|
|
tbh, prediction is the only reason I can think of. _________________ What's a signature? |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Tue Apr 13, 2010 10:53 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Tue Apr 13, 2010 11:16 pm Post subject: |
|
|
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... _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Tue Apr 13, 2010 11:27 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
|