VSync will be better when supported since it actually syncs to the monitor refresh… so no image tearing since you will never see part of one frame on half the screen and part of the next on the other half.
setFrames(60) on the other hand will just make sure the render loop doesn’t run more often than 60 frames per second. I assume that setting both will still play nice together for the times you really wanted to be sure… though personally I’d just set vsync. If the app is spinning away at 500 FPS even with vsync on then it’s something I’d want to know.
Warning when using vSynch so, it is not guranteed to be at 60z, it can also be on 120 for example (like on my old crt it was, and on professional tft’s it can be too). Don’t forget to actually calculate with the tpf then to have it framerate independent.
@EmpirePhoenix said:
Warning when using vSynch so, it is not guranteed to be at 60z, it can also be on 120 for example (like on my old crt it was, and on professional tft's it can be too). Don't forget to actually calculate with the tpf then to have it framerate independent.
Agreed... and you should do anyway because with vsync on you are also likely to drop frames here and there and the impact will be pretty large at 60 hz.
Did your tft support setting the display frequency? I'm just curious.
Ok, 99% sure that’s not timer related… but yeah, vsync related. Seems like maybe something in the sky code has to wait a frame for something and a dropped frame would be really bad in that case. I haven’t tried your test, though.
If you use setFrames(60) instead of vsync does it still have the issue?
@mifth: Thanx for posting this for me, and sorry for being late with commenting.
In my example I altered TestCharacter to use Vsync, and every second or so the screen chops, but in the game i’m working on it’s extremely pronounced and happens more frequently (too much code to provide a good testcase for debugging). My issue seems to be similar to @wezrule 's issue, and since he’s rotating a SkyBox it’s likely more pronounced than my testcase.
I will try his testcase once I get home, maybe increasing the rotation speed will increase the severity of the issue. I’ll provide a video if it’s visible enough.
@wezrule: Could you post your system specs? They might be relevant for someone
It would be useful to know which nightly build started having this issue … Its quite hard to debug like this because I don’t think there’s any change that really related to this. The only thing I can suspect is LWJGL … but I doubt it
And note that the conclusion of that thread is that for at least one person the switch to NanoTimer fixed the issues associated with beta and his continuing issues have been there for much longer. Reverting to old versions did not fix it.
Sorry. Didn't mean it that way... just didn't want to speak for you directly. There is clearly some number of issues going on and I no longer believe they are directly related. It seems the timer issue may have just made more people take notice to something that had always been there and ignored. And if there is still a different issue then it needs to be sorted. Maybe it turns out to be related.
If there are people that see twitchy behavior that exists in the latest stable version but did not exist in the pre-beta version then we need a test case for that issue.
Can you please check the lwjgl demos on their site? If lwjgl doesn’t work then there’s no chance jME3 will ever work. Also please try the OpenGL1 renderer in jME3, maybe your os doesn’t like OGL2
