Hi folks,
I'm wrestling with two different main loops in my code base.
One is server-side running the simulation but no rendering,
and the other is client-side, which needs to do some simulation
but primarily rendering.
On the server, the main loop can pretty much spin through
simulation updates as fast as the CPU can, or can be throttled
to some fixed rate by delaying until it is time for the
next simulation frame to be updated. So, I don't know, maybe
I can make it do 50Hz or so. But this should be basically
distribute all the queued events to all the correct simulation
object for their processing.
Eventually, update events (say, object position events) get all
the way across the wide 'net over to the clients, come off the
network layer, and show up as shiny new Events ready to be
processed.
So, my questions are really ones of how to set up the main loop
on the client to allow for a host of factors:
To avoid objects from "snapping" between their "current" position
and their "server-true" position, some form of "ease-in" interpolation
should be used.
So how many "current position" concepts for an object are at work now?
Add in animation frame information too, and its interpolation
between keyframes. Now we have Client simulation frame rate,
renderer frame rate, and animation frame rate.
IIRC, Eberly suggests that the Simulation is also ticked at a
frame rate lower than the physics layer, and that the Physics
handling is the _real_ driving force behind the main loop.
OK. With all that behind us and basically "assumed", (right? :-),
what the heck does the main loop _really_ look like? Is it just
time-management with delegation out to the Simulation update and
the physics update and render pass all at the "right time and
frequency"?
I think I could add more detail here for any of these bits, of course,
and I could toss out a whole day's design session around many of
the followup questions too, but I think I want to toss this out
for discussion and see where it leads us first.
I'm wrestling with two different main loops in my code base.
One is server-side running the simulation but no rendering,
and the other is client-side, which needs to do some simulation
but primarily rendering.
On the server, the main loop can pretty much spin through
simulation updates as fast as the CPU can, or can be throttled
to some fixed rate by delaying until it is time for the
next simulation frame to be updated. So, I don't know, maybe
I can make it do 50Hz or so. But this should be basically
distribute all the queued events to all the correct simulation
object for their processing.
Eventually, update events (say, object position events) get all
the way across the wide 'net over to the clients, come off the
network layer, and show up as shiny new Events ready to be
processed.
So, my questions are really ones of how to set up the main loop
on the client to allow for a host of factors:
- It should be running basically the same Simulation as on the server
- It should incorporate object position Events from the server and treat the data as authoritative,
- It should allow for simulation frame rates to be different than the rendering frame rate,
- It should allow object animation sequences to happen,
To avoid objects from "snapping" between their "current" position
and their "server-true" position, some form of "ease-in" interpolation
should be used.
So how many "current position" concepts for an object are at work now?
- Last known server-authoritative position,
- Actual rendered position,
- Simulation projected position dead-reckoning position,
Add in animation frame information too, and its interpolation
between keyframes. Now we have Client simulation frame rate,
renderer frame rate, and animation frame rate.
IIRC, Eberly suggests that the Simulation is also ticked at a
frame rate lower than the physics layer, and that the Physics
handling is the _real_ driving force behind the main loop.
OK. With all that behind us and basically "assumed", (right? :-),
what the heck does the main loop _really_ look like? Is it just
time-management with delegation out to the Simulation update and
the physics update and render pass all at the "right time and
frequency"?
I think I could add more detail here for any of these bits, of course,
and I could toss out a whole day's design session around many of
the followup questions too, but I think I want to toss this out
for discussion and see where it leads us first.
jdl