[0.16.36] FPS drop depending on zoom factor

[deepdriller]

My game runs smoothely at 60FPS most of the time, unless I'm on the middle zoom factor, especially when looking at trees, but my uranium ore patch did it too.

20180610221058_1.jpg (942.72 KiB) Viewed 3718 times

What's interesting about this image is that at the time of me taking it, zooming out just one click of the mousewheel made FPS jump back to 60.
As you can tell, I'm playing god-mode.
Yes, I did try turning on mipmaps. In fact, when I looked at the task manager and saw that the FPS drops were accompanied by GPU use surges, I turned everything on that said it might help with that.
I'm using an nVidia GeForce GTX 1050 with 2GB VRam. Since the game runs smoothely on the most extreme zoom factor (unless the trees get too dense), I'm assuming that it's not because of my hardware.

[Loewchen]

You need more than 2GB VRAM for Graphics quality: high, reducing Video memory usage should help with your issue.

[posila]

Hello. The 0.16 uses 2.5 GB of VRAM for high quality sprites, therefore the requirement for high-res was increased to GPU 3GB VRAM as opposed to 2GB in 0.15. It's possible you enabled high-res in 0.15 and it worked fine and now have problems in 0.16 because more sprites were updated to high-res and some new sprites were added. Even though we are working on complete rendering overhaul to improve the situation for 0.17, I don't accept this as a bug in 0.16.

That said, it should be possible to get 60 FPS with high-res sprites with 2GB VRAM even in 0.16: I recommend to change following things on your current settings
- enable "Low quality sprite rotation"
- reduce "Video memory usage" to high
- and possibly reduce "Atlas size" to 4096

[deepdriller]

While reducing texture quality to normal completely fixed the issue, I'm still curious about the zooming thing. It makes no sense that the game should be able to display the thickest forest at the farthest and closest zoom factor, but in between those it just quits. Is there a particular reason for that?

[posila]

Reason that happens is probably because the driver didn't manage to fit sprite atlas with trees to VRAM, so GPU sampled it from RAM, which is much slower (let's say 100times) than reading textures in VRAM.
As you zoom in, less trees are being rendered, so the GPU needs to use the slow access to RAM less often.
When you zoom out more, GPU will start sampling tree sprites from less detailed mip-level of the tree atlas, which might have been so small, that it did fit to VRAM, so GPU had fast access to it and it managed to render the frame under 16ms despite having to render much more trees.

[bobucles]

I've definitely been getting FPS drops at inconsistent times. All of the FPS drops I've seen are related to the flip[off] process, which typically sits at 0.3ms but something that it tries to display causes it to skyrocket 100 fold.

There's definitely something going on, but I can't find it by playing with graphic settings.

[deepdriller]

Could this be remedied? For instance by switching to the low-res mips when there are too many entities on screen?

[posila]

In 0.16, it can't be done without considerable effort

[Jap2.0]

In 0.16, it can't be done without considerable effort

And in 0.17?

Also, what is "flip[off]"?

[posila]

And in 0.17?

We are aiming to address issues like this with modernizing rendering for 0.17.

Also, what is "flip[off]"?

Flip is operation that presents back buffer to which the game renders onto your screen. (It's called Present in DirectX and SwapBuffers in OpenGL, Allegro calls it "flip"). Off means v-sync is off.
When v-sync is off, the time measured under flip is CPU waiting for GPU to finish rendering to back buffer so that CPU can swap it with front buffer and start queuing rendering commands for next frame.