Why is previous versions of JME having a higher frame rate than new versions?

I just realized that JME v3.3.0 has a higher frame rate than newer versions such as v3.4.1.

The images below shows frame rate i encountered when using v3.3.0 and v3.4.1.
JME v3.3.0 is overclocking 60 fps

JME v3.4.1 is limited to 60 fps

Why is the JME v3.3.0 frame rate higher than v3.4.1?
Since higher frame rate means the faster our game becomes.
Well… I don’t actually know if i’m correct :sweat_smile:

1 Like

It sounds like that is related to the vsync appSetting, which has recently been enabled by default in recent jme versions: AppSettings: change the "VSync" default from false to true · jMonkeyEngine/jmonkeyengine@f34e660 · GitHub

The wiki briefly mentions vsync (as well as some similar appSettings you may be interested in) here: jME3 Application Display Settings :: jMonkeyEngine Docs

Basically Vsync will limit the framerate to 60 fps to keep things smoother, so you don’t have situations where the game is jumping between 50 fps and 200 fps as the camera view constantly changes in a typical game. I think vsycn may also have a slight effect on input delay, but I’m not certain, so hopefully someone else can provide some more detailed info on vsync if there’s anything else important to mention.


like above mentioned. Its all about VSync. That is used in a lot of modern games.

If you disable it in app settings window, you will have non-limited framerate.

And yes, it was changed to be default setting in new versions.


Damn! I just tested and realized it was all about vsync! :laughing:


…but but I want to render at a bazillion frames per second.

…even though my monitor will only show 60…

vsync will lock the frame rate to the refresh rate of the display. It avoids wasting CPU+GPU rendering frames that no one will ever see and can also provide more accuracy for frame-length related math that gets unhappy using 32-bit floating point.

Note that JME’s frame profiling can still tell you the length of time it takes to render a frame… which in the end is a way more accurate measure than “frames per second”.