How can I set the fps separately draw and logic update rate?

Hi, sorry for the question often.
I want to update the drawing 60fps, and set 120fps that internal calculate something.
I know how to set up both at the same.

settings.setFrameRate(60);

So, can I set separately?

I’m sorry but this sounds more to me like: How can I cripple my game? That’s not a legitimate way to do things. FPS cap, sure, although why would you want to cap it at 60 is shortsighted, but limit the rate your logic will work at? Nope. Not a single reason is valid to do that.

because rendering is slow and high load.
I think it’s not uncommon to be executed in the period in which the display is different from the internal calculations, especially in low-performance platforms.
however, do you say that’s stupid? umm…
8-O

Well, having a physics thread run at a specific tick is pretty common.

Note to the OP, I used the word “thread”. Should be a good hint.

oh, same time.
thanks pspeed.
I’ve asked there is a way that in the JME3 library. (by easy way)
Anyway, I’ll try to get by. thanks

JME’s update is primarily for visual things… so it is frame locked.

If you want to run something at a different rate then you need to use a separate thread and deal with the threading issues related to that.

1 Like
@pspeed said: Well, having a physics thread run at a specific tick is pretty common.

Yes. And except for extremely specific and specialized library, when is the logic of a program intentionally set to certain number of ticks (for example)? Not that often. If we’re talking about a feature in a game, like red stone in Minecraft, yes, totally. But this is a totally different story.

What I’m understanding from the OP is that he wants to make his program runnable on the lowest hardware possible. This rarely ever goes well. People have the hardware they have and no amount of code can fix ancient hardware. Chose an absolute minimum where your “game” will run nicely on and make that a “must have”. Anything lower then you need to either upgrade of put up with it.

As far as threading goes, yes it will help, but up to a point. Again, old hardware is old…

@madjack said: Yes. And except for extremely specific and specialized library, when is the logic of a program intentionally set to certain number of ticks (for example)? Not that often. If we're talking about a feature in a game, like red stone in Minecraft, yes, totally. But this is a totally different story.
Yes, for physics often, as for example in physics bullet. It works with constant 60 fps. To keep a constant "impression" for physics I think thats necessary too. The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there's emotes that hint otherwise or there's an increased use of exclamation marks and all-capital words.

Fixed timestep is preferable when dealing with physics, networking and replay functionality. For instance most networked multiplayer RTS games uses a fixed timestep for the game logic, this is needed to make the game deterministic which enables all clients to run the same simulation which in turn is needed because the game state is so large that it’s cumbersome to synchronize all data in realtime.