Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird Vsync behaviour #2913

Open
Simonrazer opened this issue Jul 30, 2023 · 5 comments
Open

Weird Vsync behaviour #2913

Simonrazer opened this issue Jul 30, 2023 · 5 comments
Labels
bug This issue describes a bug

Comments

@Simonrazer
Copy link
Contributor

Simonrazer commented Jul 30, 2023

Description
When Vsync is turned of, I expect the framerate to be uncapped. To test this I call the game update on render, as the FPS counter of the Debug View was shown to not be reliable. The FPS seems to be uncapped, but only if the window is not in Focus, and kha reports VSync to still be turned on. See the attached video. It is a bit hard to see due to the low frame rate, but the cube spins a lot faster when the window is not focused. If it were the other way around, the fps being unlocked while the game is in the background, everything would be fine.

This happens regardless if Vsync is enabled or not. All this is regarding Krom.
To Reproduce
Have a way to reliably measure FPS. and notice a difference beteween focused and unfocused window behaviour

System
Blender: 3.6.1LTS
Armory: current ArmSDK
OS: Win 10
Graphics card: GTX 1060

vsync.zip

@Simonrazer Simonrazer added the bug This issue describes a bug label Jul 30, 2023
@rpaladin
Copy link
Contributor

I tested your blend. I couldn't produce the same weird behavior, and I tested with both v-sync enabled and disabled. I wonder if this is because I'm on Windows 11 which separates the Blender terminal as a separate process/application, unlike with Windows 10.

@Simonrazer
Copy link
Contributor Author

I can confirm, on my Win11 laptop Vsync seems to work fine

@MoritzBrueckner
Copy link
Collaborator

I also cannot confirm this issue on Windows 10. Armory reports exactly 2500 frames per second (this seems to be the maximum for my AMD RX 6700 XT GPU) and I can hear coil whine from my GPU which I only experienced with very high frame rates so far. Unfortunately, the AMD overlay doesn't seem to recognize the Armory game so I cannot see the frame rate as reported by the GPU.

In my case I couldn't see the cube spinning as fast as in your video, also the script that is shown at the beginning of your video is missing. Maybe that's the reason why it works for RPaladin and me?

Also make sure to check your GPU settings, at least AMD has a setting to enable vsync even if a game tells the GPU otherwise.

@Simonrazer
Copy link
Contributor Author

The cube in my original .blend was spun via logic nodes.
For the spin-speed difference to be noticable in that .blend, the logic rate had to be tied to the frame rate with a little change in Iron's code. (Armory has a logic tick system, running 60 times a second by default)
Here is a new setup, where the spinning of the cube is already bound to the frame rate via a Haxe script, so no changes are required. It also prints a Framerate in the console.
vsynctest.zip

@MoritzBrueckner I don't fully understand, does the behaviour you describe happen when Vsync is en- or disabled? I have no Frame limiters, or any such things, enabled

@MoritzBrueckner
Copy link
Collaborator

MoritzBrueckner commented Aug 26, 2023

Hi, sorry for my late answer. Now with the new file I think I understand what you mean, although I still cannot reproduce the issue in the way you experience it. The debug console shows the average frame rate, which differs from what is reported in the Blender console by your script. However, even after changing the debug console to print the current (non-average) frame rate there are huge differences:

VSync Full screen FPS reported by debug console (approx. & non-average) FPS reported by script (approx.) FPS reported by AMD overlay
On No ~165 (my monitor refresh rate) 2000-8000 not specified, seems not to work with windowed mode
On Yes ~60 (???) 2000-4000 60
Off No 1000-1600 8000-20000 not specified
Off Yes 700-900 6000-12000 700-800

Note that the AMD overlay decreases frame times by a bit. I have no idea why full screen and VSync result in 60 fps for me...
Whether the windows is focused or not doesn't make a difference for me (independent of whether VSync is on or off).

The debug console calculates the current (non-average) frame time as follows: Scheduler.realTime() - lastTime, so the frame rate would be 1 / (Scheduler.realTime() - lastTime). Your code uses 1 / iron.system.Time.realDelta. I'm not really sure which way is more correct here, but apparently there is a huge difference. If your custom framerate is more correct this means that VSync doesn't really work, but I still think it does (at least in windowed mode) since the debug console then reports the correct frame rate.

How I modified the debug console (original source):

ui.text("Frame");
ui.text('$avg ms / $fpsAvg fps', Align.Right);
ui.text('Current: ${Std.int(1 / frameTime)} fps', Align.Right);  // added this line

I don't fully understand, does the behaviour you describe happen when Vsync is en- or disabled?

What I mentioned above was with VSync disabled.


Since Armory only passes a vsync flag to Kha, this is more likely a Kha issue I guess, can you reproduce your issue in a pure Kha application?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue describes a bug
Projects
None yet
Development

No branches or pull requests

3 participants