You contradict yourself. It will not be faster than simpleUpdate (). It seems only yan, in the subject…
Yan showed you how to create a thread that should have been a Callable<Spatial> if you want your model back in the main thread. I have no idea how that corellates to what you want. Im lost. Make a threadpool. Manage it.
I just want simpleUpdate () to be called the same on all PCs, regardless of the screen frequency.
In fact, Paul has answered this question in the very beginning.
Seperate the calculation a part from the visual things. Thus, start another thread to do the logic, SimpleApplication only request data about how to update the scene from that thread.
Paul made an framework named zay-es , with a Entity System you can easily do this.
He also made a game example named MonkeyTrap , it shows how to do the game logic in a standalone server thread.
This is the standalone GameSystem , which runs all the gameservice in a fixed rate.
SimpleApplication and all the AppState only do the visualizition. this is an example.
I think it’s easier to abandon the idea of multiplying, rotating the character on tpf. Naturally, it was stupid of me, the mouse angle sets the actual rotation, and not the application cycle.
The topic is not relevant. Thank you all for watching the “idiot” series and jME3. 
Hey, but you are smarter now, arent you? That’s for sure something positive!
Just one note: Multiplying by tpf is what makes it the same on each computer.
If the update method is called twice as often (due to high fps), then tpf is only half as big, so in sum you move the same.
Obviously the resolution is higher with higher fps, but since it takes you 1 second to move over the screen, that’s ~30 pixel per update call at 60 FPS, so you already have a really smooth movement
This does not work in my mouse implementation. Using tpf gives the reverse effect.
Probably because it’s multiplied by tpf twice, like something from the inputManager is already premultiplied. But I don’t remember that correctly.
It’s easy to find out though
As I’ve said a few times now, the mouse movement already effectively has TPF built into it because it is being sampled at the frame rate. The mouse movement already is frame-rate-dependent. Multiplying mouse motion by tpf is totally 100% wrong… and it’s wrong that JME does this by default. (Lemur’s InputMapper fixes this.)
1 Like
Note that MonkeyTrap is very old. It’s still probably a decent example conceptually I guess but some of the classes have been standardized by now.
For example, GameSystemManager in my SiO2 library:
It would be interesting to rewrite MonkeyTrap some day to use the utility classes in SiO2. It would simplify a few things… but probably in the end make it a worse example for teaching ES concepts.
Edit: for usage examples see sim-eth-basic and sim-eth-es examples already referenced.
1 Like