Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Seems to work well in a bot DM running cl_maxfps 20, 72, and 999 (actual about 180).
Suggest trying delta = 1/min(cl_maxfps.value, 72) I know the point is framerate independent. But in software engine, physics rate should not really be more than framerate.
More elegant than the previous physics throttling solution. Interesting that SV_RunClients is now within the throttled loop.
Framerate-independent physics
Moderator: InsideQC Admins
15 posts
• Page 1 of 1
Framerate-independent physics
by mh » Sun May 15, 2011 10:54 pm
-
mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
by r00k » Thu May 19, 2011 7:56 am
Some attempts rendered no trail yes. altering host_frametime more particles. I wanted a consistent number of particles for trails no matter how fast or slow they moved. Like you said, distance might be a good baseline to create an algorithm around.
- r00k
- Posts: 1111
- Joined: Sat Nov 13, 2004 10:39 pm
by mh » Thu May 19, 2011 6:13 pm
OK, I was talking rubbish. I've managed to reproduce Spike's error, and it's nothing to do with timer precision. 
This description is for NQ, but I assume that QW does something reasonably similar.
On a frame when the server runs we get a full read on the client.
On a frame when it doesn't run we get no read on the client.
In both cases CL_RelinkEntities (which generates particle trails) runs.
If the client is running faster than the server, the entity remains on the client but it's new origin doesn't get updated. In order to generate a particle trail we need to:
- Copy current origin to old origin.
- Advance current origin by the lerp position determined by CL_LerpPoint.
- Generate particles between the two points.
However, if the client is running really really really fast, the difference between old origin and current origin will be negligible on successive client frames; at least for the purpose of generating particles.
Soooo... how about this?
- Check for particle trail effects in CL_ParseUpdate instead of in CL_RelinkEntities.
- if ((bits & U_ORIGIN1) || (bits & U_ORIGIN2) || (bits & U_ORIGIN3)) generate particles.
- use ent->msg_origins[0] and ent->msg_origins[1] as the start and end points (or should that be the other way around?)
This description is for NQ, but I assume that QW does something reasonably similar.
On a frame when the server runs we get a full read on the client.
On a frame when it doesn't run we get no read on the client.
In both cases CL_RelinkEntities (which generates particle trails) runs.
If the client is running faster than the server, the entity remains on the client but it's new origin doesn't get updated. In order to generate a particle trail we need to:
- Copy current origin to old origin.
- Advance current origin by the lerp position determined by CL_LerpPoint.
- Generate particles between the two points.
However, if the client is running really really really fast, the difference between old origin and current origin will be negligible on successive client frames; at least for the purpose of generating particles.
Soooo... how about this?
- Check for particle trail effects in CL_ParseUpdate instead of in CL_RelinkEntities.
- if ((bits & U_ORIGIN1) || (bits & U_ORIGIN2) || (bits & U_ORIGIN3)) generate particles.
- use ent->msg_origins[0] and ent->msg_origins[1] as the start and end points (or should that be the other way around?)
-
mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
15 posts
• Page 1 of 1
Return to Programming Tutorials
Who is online
Users browsing this forum: No registered users and 2 guests