[Solved]fps vs logic update speed (jme3)

Hi!

I was wondering if there’s a built in way of separating the update speed for rendering and the update speed for game logic

they seem to be the same (limited by the fps)

Say maybe I want the renderer to update only 60 fps as in with VSync on, but the updating of game logic (ie. simpleUpdate) should go 200 times a second…

in order to do this should I make my own SimpleApplication2 that extends Application ? I mean, there’s no built in way to do this otherwise? (I think there was something in jme2, that’s why I’m even asking)

No and there was nothing like this in jME2 too.

1 Like

oh you’re right, I actually had to merge these two (in jme2):

http://code.google.com/p/jmonkeyengine/source/browse/branches/jme2.1/src/com/jme/app/FixedLogicrateGame.java

http://code.google.com/p/jmonkeyengine/source/browse/branches/jme2.1/src/com/jme/app/FixedFramerateGame.java



Thanks!

Most applications do it this way. There’s no need to make updates that you cannot see.

1 Like

Don’t read this, is irrelevant anyway, but imma still post it xD


I dig that but that may really not apply to me, of course I may be doing the entire program wrongly and the fact that it doesn't apply to me should be my first clue to that...

like for example here (well actually not really that one, more likely this one where I can manually slow down the logic update with Thread.sleep by pressing left Alt / LCtrl keys when moveSpeed is 20f ), I have this program that adds a spline point to the curve on each update but if something happens and the update is delayed like 1 second or 4 seconds even, the point will be rather far and the curve will look jagged (of course I could try and add more curve segments but that would apply to the entire curve not just to the last two spline points => bad)

Well, actually the update may be delayed not just because the video card cannot handle the rendering in due time, in which case my program will still fail as described :) but at least if the update is limited by the VSync which usually means called 60 times per second, then if I happen to need a faster logic speed than that, .... well I'd have to have it called faster or so... anyway, it's sort of well known(at least they hint to this in portal 2 game when fiddling with vsync setting: `mouse lag` they call it) that if you turn VSync on you can have a laggier reponse time(ie. in multiplayer 1st person shooters) and most likely that's due to logic+rendering happening at the same rate of 60fps (or wtw VSync resolves to for the running computer) instead of 1000fps or well 200fps :) - the display cannot show me more than VSync(ie. 60) fps anyway.

Anyway, no worries, I'll try to do my own impl. of that ...
Good talk :)
Thanks

Your problem happens because you’re doing an operation per update call, not per unit of time. Because of that, your application is strongly framerate dependent and will not work the same across different computers.



You can split the TPF into sections and then emit however many points fit into the TPF, then store the remainder, which gets added to the next frame.



In fact this is how the jME3 particle system works, it must emit X particles per second:

http://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/core/com/jme3/effect/ParticleEmitter.java#638

1 Like

that is exactly the effect I was hoping to get out of having different rates for render update & logic update

thanks! that was most useful



I eventually made this post with the code reflecting this.

(just for learning purposes only, I’m not planning on doing anything else with that code)



now I wonder if I can generalize this… xD

Momoko_Fan said:
Most applications do it this way. There's no need to make updates that you cannot see.


Actually, there is sometimes a need to perform updates that you cannot see.

The simplest example that I can think of is an accurate simulation of planets orbiting a star (or any system of more than 2 objects orbiting each other, really). If you want it in realtime, then for better performance you want it to calculate changes in position as fast as possible, but there's no need to waste time rendering things every time you recalculate a position. In fact, wasting time calculating anything other than the positions will take time away from the position calculating and therefore is counter productive and reduces precision.

In this situation, the best way to do it is by separating render frame rate from world update tick rate. Let the world update process at unbounded speed and the render frame rate at 60hz or 120 or whatever.

Another example is complex collision interactions with fast-moving objects. The easiest way to handle some of these scenarios is to simple increase frame rate, and again it doesn't make sense to update anything more than necessary at rates that users cannot appreciate visually anyway.

I'm not trying to be a nit-picker. I've just had this scenario come up a few times before. In addition to making games, I have also done some work in physics applications, including real-time physics simulations.

Besides, having a good time-keeping subsystem is a must for any game that manipulates the passage of time in any way. Maybe this is something to put in the back the collective jMonkey mind for a low-to-mid priority future addition.

Almost all of these situations should offer some way to work around that. Just as bullet uses ccd to avoid problems with too high velocity (where the first thing that comes to mind is just upping the physics resolution). This is a problem of all computing algorithms as on a computer you always work with quantized values instead of “real life” values. Same accounts for number accuracy. If you feel you have to up everything to 64 or even 128 bit then I argue you are doing something wrong.

1 Like

I tried to solve similar problem by introducing thread that updates logical state of world and sends messeges to graphics thread about changes.

That second thread advances simulation time each step and computes state in which world will be one step later and waits to make each step uniformly long. It also provides estimate of logical time (this estimate expect to each step take as long as previous).

Graphics thread knows (from messages) current state, next state and estimated time, so it can interpolate things to smooth movement.



It worked somehow (I used it in my flocking experiments), but was overingeneered. So when I learned how to use JME physics, I switched to it.

Btw, if I set threading mode to parallel, does I get something similar? Or It still is framerate dependent?

The parallel physics (as the javadoc states, eherm) runs in parallel to rendering, apart from that its dependent on the update loop yes. If it was not, you would have to separate all your code in “stuff that modifies physics” and “stuff that modifies graphics” and make it thread safe etc etc

1 Like