If your game objects are operating on their own frequency then you will need a separate thread (and all of the garbage necessary) to manage that.
But really, tpf should be fine for any reasonable update rate. When you turn vsync off, you essentially throw away work all the time as only updates at your monitors refresh are going to be displayed anyway.
Different from what? You are essentially calculating the tpf the same way JME does.
It’s showing you how much time has passed since the last frame was rendered. Generally, this is enough to update the visualization since you need to know what to render at the current time.
In most cases it is unnecessary. Indeed, you are only having problems because (I think) you are trying to do a bunch of strange things.
When you have advanced enough to know the difference then it will be a simple thing to create a separate update loop for your game simulation as you’d have defined an architecture that decouples the game objects from the visualization.
Else, simpleUpdate() or rather the AppState and Control updtaes, will be fine for your needs.
The fact is that this is a problem of accuracy targeting the partner’s head. The mouse is not smooth with a small amount of FPS. This is also not reasonable, with players with different monitors. In a multi-player game with a monitor with a higher screen frequency, he has the advantage. Because he has a banal faster in the game are calculations.
In fact, when you run un-vsynched to let frame rates get unrealistically high then mouse sensitivity typically goes DOWN.
And in the end it doesn’t matter as the mouse is only being sampled as often as the update rate anyway and the user can drag that mouse as fast/slow as they want. I fail to see how different clients benefit from that in a way you can/can’t control. This is why hardcore FPS games buy really expensive high-resolution mice, too.
I wonder why you are manually sampling the cursor position instead of using the built in mouse support or something like InputMapper? InputMapper (as already posted in an example) would allow you to treat joystick, mouse, direction keys, all as the same “axis” of rotation. Then multiply those values by tpf to scale them to frame rate.
At 60 hz you will display how far the mouse has moved in 1/60th of a second.
At 120 hz you will display how far the mouse has moved in 1/120th of a second.
These two things (input and display) are TIGHTLY coupled… it cannot be otherwise.
Anyway, I’m done having this conversation. You have your mind made up and can only provide one-liner responses instead of well thought out explanations. So I will wish you luck with your game and the problems that only you seem to be having… and call it a night.
Go through the tutorials. They explain how to use jMonkeyEngines framework.If the tutorials do not provide the information you seem to have trouble understanding, then perhaps a lower level Java development introduction is required. At any rate, this thread seems not related to JME or Java, but of time coupling on distributed systems.