NextThink or StartFrame?

[Quake Matt]

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?

[Sajt]

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.

[FrikaC]

Doing anything with physics in thinks is kind of silly.

[Quake Matt]

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.

[FrikaC]

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...

[Quake Matt]

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...

[FrikaC]

Code: Select all

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.

[Sajt]

That function should be called pow, not exp :O
Actually it should be called something like babypow.

[Quake Matt]

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!