Been searching for a few hours on how to enable a fixed-update rate in JME3. I have run across many code examples of ‘FixedLogicrateGame’ from what appears to be JME2, but can find no reference to similar implementations for JME3.
Has this gone away completely, or has the class been replaced by separate functionality elsewhere?
I am specifically looking on how/where to set the logic update rate independently of the frame-rate.
(there is no need to update physics/logic at 60+fps, but many reasons to use fixed-update/logic timing)
Its gone, if you really need a fixed rate update loop (most would say that your app design needs to get to the 90s) make your own and use the gl view asynchronously as you would with swing.
I’m not sure that I need a fixed update timing, but it would seem to simplify many things for a physics based networked game. Probably mostly because its what I’m used to (been doing Minecraft modding for awhile now), and I’m not sure of other ways to make the physics/update calculations discrete/predictable on both clients and server. (and yes, many who have seen Minecraft’s codebase would say that Minecraft needs to get with the 90’s as well )
Anyhow, I guess I will investigate alternate solutions to fixed-rate logic for network synching and physics purposes. I am open to suggestions if any have them
I’m not sure that I need a fixed update timing, but it would seem to simplify many things for a physics based networked game. Probably mostly because its what I’m used to (been doing Minecraft modding for awhile now), and I’m not sure of other ways to make the physics/update calculations discrete/predictable on both clients and server. (and yes, many who have seen Minecraft’s codebase would say that Minecraft needs to get with the 90’s as well )
Anyhow, I guess I will investigate alternate solutions to fixed-rate logic for network synching and physics purposes. I am open to suggestions if any have them
I think you may have misunderstood the Valve articles. Discrete time steps are not an absolute, really. You can’t reliably count on the time anyway. They can vary somewhat and the math will still take care of it. In their case, the times steps are more for sampling. I’m sure their physics engine still uses frame time to step the physics the appropriate amount.
…and in any case, this has little to do with the render loop which will be interpolating values anyway.
In the Valve articles, all physics is really done on the server and that’s the approach I also recommend. And for sure then the JME update loop has little to do with how the objects move.
Run the game state in a separate thread. You will have jitter; either ignore it, or make the physics loop higher-priority than everything else (NOT RECOMMENDED), or include the actual time elapsed in the calculations. (Ignoring might actually work well enough.) You need to somehow move the results from game state thread to render thread, the usual and recommended way is via Application.enqueue().
Run the game state calculations inside the render loop. You do want to account for jitter there, i.e. interpolate over longer times for larger tpf values. On the plus side, you get a rock-solid tpf value (which is surprisingly hard to get right), and you don’t need to worry about threading issues. On the minus side, you’ll never be able to exploit more than one CPU core. (I forgot to add: Also, the advantages do not carry over to client-server configurations, so if that is something you want to keep in reach, this approach is definitely the wrong one.)
Just throwing this out there for whoever/whatever… yeah… I know… this thread was necro’d, but here it is anyways.
2D physics requires a fixed rate update loop… so if you are sure that this is what you require, take a look at dyn4j or box2d examples to see how this may be implemented for whatever your purposes are.
)
)