[SOLVED] Problem with simpleUpdate

As you know, I’m still writing FPS camera.

But after spending some time with jME3, I found the source of all problems with not correct behavior with a high frame rate.

The fact is that the simpleUpdate method is called only when the frame is rendered. It is not right. Calculations of the renderer and processor calculation should not be related.

Evidence. Try turning on and off the vertical synchronization, you can also set the parameter for the cleanliness of the experiment setFrameRate ();

package test;

import com.jme3.app.SimpleApplication;

public class Main extends SimpleApplication {

	private static Main app;

	public static void main(String[] args) {

		app = new Main();


	private long last_time;

	public void simpleInitApp() {


	public void simpleUpdate(float tpf) {

		float delta_time = ((System.nanoTime() - last_time) / 1000000.0f);


		last_time = System.nanoTime();



And the render time of the frame will be different :scream:

simpleUpdate is to update your visualization.

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.

Then I was wrong.

In jME there are tasks for calculations?

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.

P.S.: have you done all of the tutorials?

I do not need a textbook to understand that the frequencies of 60 frames for accurate positioning are not enough.

If you are only displaying things at 60 frames per second then why is it not “accurate enough”? In fact, most games that decouple their physics from display do it to have a SLOWER physics update.

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.

Not if tpf is used properly.

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.

And with large drops of FPS, the sensitivity of the mouse will change. What is not permissible in the game. This effect is in my code sample.

I need advanced control over the mouse, since I want to limit the rotation of the mouse along one of the axes. And much more.

Believe frame rate decides I’m a player in online shooters. When playing with a monitor 144 Hertz, I put the heads easily, than 60 hertz.

If you are under the constraints of 60 and without restraint, take a closer look at the details, you will see jerks.

Do note: for mouse movement, tpf multiplication is likely unnecessary as it’s already got time factored into it. JME unfortunately premultiplies it in its mouse motion events.

It’s not like a normal joystick axis where speed=1 needs to be multiplied by some current tpf. The mouse motion is already “all the motion in that frame” and needs no additional tpf.

Nope. I never do.

Edit: I may have misunderstood what you said. I always run vsynched because to do anything else is dumb for normal play.

So the fact is that the time is summed up, from the missed frames. This is what I wanted to say to the example.

At different frequencies, these are different values.

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.

Good luck with your game.

To render the frame, the display time is required, and not the difference between frames for normal smooth rotation.

Good luck with your game.

com.jme3.system.NanoTimer already did what you do, and the paremater float tpf is the results.

In another word, tpf == delta_time.

Hmm, but the fact is that with 60 frames simpleUpdate for 1 second will work and update the world 1 time, 120 frames 2 times. Is there a difference?

Edit: More precisely, 60 and 120, the ratio 1/2

Yes, I did this, but now it remains to understand how to perform calculations in the CPU flow. And not when rendering. Need something like a task manager.

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.

1 Like