non-smooth background scrolling while running

[leaf-node]

I tested flare with an x60 (with a T2400 cpu) and an x201 (with an i5-540M cpu) in Debian jessie. I noticed that on both machines the background did not scroll completely smoothly. This phenomena is distinct from a consistently low frame rate which causes the background to appear somewhat blurred.

On the x201 and x11, the scrolling was almost perfectly smooth, but the background would lurch (perhaps lag or stop moving) for a frame or more, at a consistent frequency of about once per second (in whichever map I tested). The frame rate was 60 fps.

On the x60, this often occurs around 5 times per second, under x11. The frame rate for this machine is variable, around 40-60 fps, depending on the map location. This frequent lurching occurs even in the teleport ring map, where the frame rate is consistently 60 fps.

[dorkster]

I see this behavior as well. It appears to be a bug with the frame-skipping code that I wrote, since it doesn't happen when I execute logic + rendering exactly once every frame AND disable our SDL_Delay() call. I'll look into it.

[dorkster]

I just pushed https://github.com/clintbellanger/flare-engine/commit/440398c6d6d81ca771734dbdda832c1d573e8967. It should fix this issue, or at the very least, improve it. If you drop below the framerate cap, the stutter might still appear. But for me, it's gone when maintaining 60 FPS.

[leaf-node]

if my measurements are correct, rendering on the x60 takes 3 ms each frame, but pushing the image to the screen usually takes longer than 13 ms when using vsync. occasionally it takes less than 13 ms. i wonder if a large portion of that time is due to anything like frame synchronization or timing issues (if such things exist.)

in any case it might be a good idea to target low fps systems with automatic fallback to 30 fps for consistent display. (even lower rates could be 20, 15, 12 fps, etc.) on the other hand, disabling vsync already achieves 60 fps on the x60 and gives a significant visual improvement over the variable fps vsync mode. perhaps a consistent 30 fps with vsync would look better than 60 fps without it.

[leaf-node]

i noticed that when setting max_fps=30 in .config/flare/settings.txt that the background lurches every one to three seconds or so.

[dorkster]

Strange, since vsync is the only way I can get things to look smooth. It's hard to tell if 60 + no vsync would be smooth for me, since my monitor is a TV that has a weird 59-point-somthing hZ refresh rate. With vsync on, Flare reports to be running between 58-60 fps. With it off, it's a flat 60.

Anyway, here are my findings when testing 30 vs 60 fps and vsync on/off:

max_fps	vsync	stuttering?
30	no	yes
30	yes	yes
60	no	yes
60	yes	no

So I think there still may be a rounding error or something, since I should theoretically have no stuttering with 30 fps and vsync on.

[dorkster]

809da7ce0737035dd6039ede6843a2872fc3af7e should be more of an improvement. It seems to have eliminated any of the large "lurches" at both 30 and 60 fps caps.

[dorkster]

Please try 0b257ed6e2db6227a88eebc70676af80b9f91409. With it, I have no more stuttering with any FPS/vsync combination.

[leaf-node]

I'd say that 0b257ed6e2db6227a88eebc70676af80b9f91409 and the prior commit a16c9703e9ea038ee4326d655c4b6625f7429b2a are about the same. It's hard to compare subtle compounded effects by recorded description and/or memory, so these results are approximate. I'd say that the last result is quite surprising.

I don't consider jitteriness to be a problem given the capabilities of the hardware. It seems that low frequency jitter is more distracting than high frequency jitter.

max_fps	hw surface	vsync	appearance
30	no	no	quite good. on 1080p there is some minor lurching
30	yes	no
30	yes	yes
60	no	no	jittery. on 1080p it is a little lurchy
60	yes	no	jittery. on 1080p frequent significant lurches
60	yes	yes	low frequency jitter. occasional lurch. on 1080p: jittery but very nice. only occasional stutter

I believe that use of an 1080p monitor produces different results due to the different display ratio (and therefore dimensions and size of the map.) Prior tests without the 1080p monitor have been with the x60 screen, which is 1024x768 pixels. The 1080p monitor seemed to cause more issues on the x60. I'd say that these results range from pretty good to good.

The issues fast hardware experiences are different than those of slower hardware, so optimizing for one may not help the other. If you want better results than these, I recommend buying an old piece of hardware to tighten the testing loop. I'm willing to do some more tests, but I might not be quite so frequent, as they can take a while. If you're looking for old hardware, the x60 is pretty much on the fence performance-wise. You could even install coreboot on the x60 if you're feeling adventurous. : )

Another consideration is that graphical quality may be randomized. The start of the first cycle is determined by the exact timing that the program executes. After that, each cycle starts an average of 16.67 ms after the prior one. This means that the time available for frames to reach the screen is consistent within a particular execution, but different across executions. This could cause chaotic results across executions, which is a problem in its own right, but may make comparison of test results more error-prone.

[dorkster]

It doesn't surprise me much that the commits produce roughly the same results for slower machines. I do most of my development these days on a machine with a 3.4 GHz AMD CPU and an nVidia 750 ti GPU (proprietary driver). Yet, I was still getting lurching before the last commit, which was an indicator to me that our frame timing was wrong.

I also do testing on an old Asus EEEPC 1005HA, which has a 1.6 GHz Intel Atom CPU and an Intel 945 GSE integrated GPU. On that machine, maintaining 60 FPS can be difficult if not impossible, and drops are more inconsistent. One could argue that capping the FPS to 30 leads to a better experience there, since the frame rate will be more consistent. At this point, I'd say that is more of a raw performance power than a frame timing issue.