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]

[FrikaC]

[Sajt]

[Quake Matt]