View previous topic :: View next topic |
Author |
Message |
Quake Matt

Joined: 05 Jun 2005 Posts: 129
|
Posted: Wed Mar 08, 2006 6:19 pm Post subject: NextThink or StartFrame? |
|
|
Right'o, it's about time I made Gyro II, which means that I've got to come up with a good way of getting regular physics updates.
Last time, I was running the physics with the usual time + something system, that kinda worked okay for the most part. However, because the engine physics were iterating faster (most of the time!), Gyro didn't fit in as perfectly as I'd have liked. Most obviously when objects were set to being weightless, yet they'd still drift up or down slightly depending on the framerate.
I'm tempted, this time round, to bind Gyro to the StartFrame function, so it iterates just as quickly as the engine physics. There's a couple of problems with this approach, of course, but I should be able to work around them one way or another!
So, what would the experts suggest? Would using StartFrame screw up the netcode or slow the game too much? Should I instead try to add framerate compensation into the older nextthink sytem? |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Wed Mar 08, 2006 6:40 pm Post subject: |
|
|
I'd go with StartFrame... probably isn't going to screw up the netcode, seeing as how the engine code updates the same stuff every frame anyway. _________________ 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 |
|
 |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Wed Mar 08, 2006 9:51 pm Post subject: |
|
|
Doing anything with physics in thinks is kind of silly. |
|
Back to top |
|
 |
Quake Matt

Joined: 05 Jun 2005 Posts: 129
|
Posted: Fri Mar 10, 2006 2:23 pm Post subject: |
|
|
Well, thinks worked okay for instant forces like explosions, but were pretty unreliable for more constant forces.
How exactly does startframe work on, say, a dedicated server? Does it get fixed to 60 calls a second, or does the server just spam it as quickly as it can?
Of course, a problem with non-fixed timing of startframe is that everything needs to be scaled, which is an pain to do without native support for exponentiation (unless I missed it somewhere!). Either I'll have to go with an estimation function, or simply scale the number of Gyro loops every frame, effectively fixing it at 100 iterations per second or something. |
|
Back to top |
|
 |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Sat Mar 11, 2006 3:09 am Post subject: |
|
|
On a dedicated server, as on any other server, StartFrame is called every frame. Frames on a dedicated server are dictated by the sys_ticrate variable.
Without native support for exponation? There's the * operator..... Of course everything needs to be scaled by frametime, you ought to be doing that anyway... |
|
Back to top |
|
 |
Quake Matt

Joined: 05 Jun 2005 Posts: 129
|
Posted: Sat Mar 11, 2006 11:52 pm Post subject: |
|
|
I mean there's no support for x^y without using QSG extensions, which makes it difficult to time-scale multiplications. I fear that an estimation function would either be woefully inaccurate or expensive to perform, but I'll look into it and see what I can come up with.
But still, at least I know it's safe to use StartFrame! I've always been a little cautious around it and the playerprethink function... |
|
Back to top |
|
 |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Sun Mar 12, 2006 1:30 am Post subject: |
|
|
Code: |
float exp (float a, float b)
{
local float n;
n = 1;
while(b > 0) { n = n * a; b = b - 1 }
while (b < 0) { n = n / a; b = b + 1 }
return n;
}
|
doesn't deal with fractional powers, but close enough, rint them or something.
It's always better to deal with constant powers as such: x to the 5th power: x*x*x*x*x inline with the code, that's 5 opcodes run during execution.
Calling this function would be 3 for the call itself, 5 for the first while check, 5 to 10 (depending on the compiler optimiztions) for n = n * a and 5 to 10 (depending on compiler again) for b = b - 1. 5 for the goto at the end of the while 1 to bypass the second while and 1 for return. So upon execution this function would cost between 25 or 35 opcodes to raise to a power of 5. That's not too bad, and obviously it gets worse the higher the power, but it's acceptable for many situations. |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Sun Mar 12, 2006 1:54 am Post subject: |
|
|
That function should be called pow, not exp :O
Actually it should be called something like babypow. _________________ 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 |
|
 |
Quake Matt

Joined: 05 Jun 2005 Posts: 129
|
Posted: Sun Mar 12, 2006 12:43 pm Post subject: |
|
|
Quote: | doesn't deal with fractional powers |
Yeah, that's the problem. Ideally, all time-related functions would use seconds as their unit, but without fractional powers, this can't be done accurately. It's not such a problem if I use smaller time units, but then it's a case of trading speed for accuracy, as smaller units mean more iterations of the above pow function. It's always an idea to fall back on, but I'd like to try other techniques out first.
For now, I'm going to keep experimenting with approximations. Normally, framerate shouldn't be any less than about 40fps, which means I should never need to raise higher than about x^0.025. And if I cap Gyro at around 80 iterations a second, the power should never be lower than x^0.0125, which makes life easier! |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|