Can't get 60FPS in fullscreen (Windows 8.1)

#1

Hi! I’ve been seeing this issue for several months, but haven’t been able to find a good fix yet. Maybe someone can help!

If I run my Windows build on Windows 8.1 (I’ve tried it on 2 computers so far) with vsync enabled and at 60fps, it runs very nicely in windowed mode, even maximized. But as soon as I hit Alt-Enter, framerate starts to vary wildly between 40 and 60 fps.

It’s not slow hardware or bad optimization. Because if I set the fps to 90 (again with vsync enabled) in application.xml, it fixes the problem and gives me a silky smooth 60fps in fullscreen (because my display refreshes at 60Hz). Obviously this isn’t a good workaround in many cases, though.

The problem doesn’t exist on Android, Linux, Mac, or Flash targets, or even if I run the Windows build on a Windows 7 machine. I’ve tried both onboard and dedicated graphics cards, and both have the problem I described in Windows 8.1.

Here are my version numbers:

hxcpp: [3.1.68]
lime: [2.1.3]
openfl: [2.2.8]

And here’s the window node from my application.xml:

<window width="1152" height="720" fullscreen="false" resizeable="true" orientation="landscape" vsync="true" fps="60" unless="flash" />

I know similar questions have been raised in the past, but I haven’t seen a resolution for any of them that fixes my problem.

Thanks to anyone who has any ideas!

#2

have you tried adding these attributes to the window tag?

<window hardware="true" allow-shaders="true" require-shaders="false" if="cpp"/>
#3

Would you mind testing to see if this occurs on Windows with the newer OpenFL 3.0.0 code, or does it only occur in legacy?

Your full project might not work with the newer code yet, but a simpler sample to recreate the issue might help us know.

Either this is something that is resolved with the newer frame timing, or perhaps this is due to less accurate Windows timers

#4

I have similar issue with Intel GPU and window mode, but not with fullscreen mode or NVIDIA GPU.
Intel GPUs emulate vsync in window mode using Sleep(), which is affected by Window’s timer resolution.
Windows’s default timer resolution is 15.6ms and that shouldn’t be enough to emulate vsync.
Tested with “next” version of OpenFL.

Next Lime always uses timer to wait for 16ms, whether vsync is enabled or not. I think this is problematic, too. If vsync is not enabled, that should make FPS 62.5, not 60.

Lime is using SDL’s timer internally.
I suppose SDL_Timer uses QueryPerformanceCounter on windows, so this is not affected by timer resolution. QueryPerformanceCounter may not work correctly in all situations, though.

Game Timing and Multicore Processors (Windows)

Stuttering when running application in windowed mode
#5

I’ve heard that setting the framerate to 61 is enough, but I don’t know it that applies to the latest version.

#6

Thanks, I hadn’t tried all of those. I just added that line, but unfortunately I still have the same result.

By the way, is hardware rendering turned off by default on cpp?

#7

Yeah, I had heard that too a while back, and it might still be true in some cases. Right now I have to ask for at least 80 to get a smooth framerate on my dev box though.

#8

I was hoping the new timing would fix it, actually. I spent a couple of hours yesterday trying to get it to work with OpenFL 3.0.0 and Lime 2.3.0. Eventually I was able to get the project to start, though it’s still not working very well in that version. Here are the results:

In windowed mode, I’m still getting 60fps.

If I start the project in fullscreen mode, it takes about 45 seconds to initialize, and then seems to be stuck at 31 fps. I haven’t been able to figure out why yet. If I start in windowed mode and then hit alt-tab, the result is similar – it hangs for several seconds and then gives me a framerate of 31. It’s a steady 31, though.

But to answer your question, I do think the new timing fixes the problem. I tried some sample projects (BunnyMark and PiratePig) and they have the exact same problem on my computer if I run them at 60fps+vsync in 2.2.8, but it’s fixed in 3.3.0.

I probably won’t get a chance to troubleshoot the 3.0 beta in-depth for a couple of weeks, but after that I’ll be sending you lots of feedback. :grinning: Thanks for your help and for a great open platform.

#9

Good, that’s great to hear. If the fix is “in the pipe” then I’m less worried, we’ll continue to work on the newer code to boost up the performance, and please report any issues you had in compatibility. Thanks!