Based on my analysis of different graphics options used during a playthrough of the latest 0.9 devbuild, I have some suggestions for what settings to use for a Low Performance Graphics Preset.
Disable Microbe Ripple Effect. This is the most performance intensive default setting, and cuts the fps in half in both the early and late game.
Disable MSAA. This gives a significant performance boost across the early and mid game, still giving a useful performance boost in the end game as well. Using FXAA instead did not noticeably change performance any more than disabled AA on my machine, so we could consider using FXAA on the preset instead. but fully disabling AA would be the safer option initially at least.
No other graphical setting seems to make much of a difference to the performance on this machine at least. So these are the only two I can confidently suggest.
There is one last important graphical setting, the resolution scaling option, which does have a big effect on performance. But I am not sure if we would want to set a lower resolution by default in the low performance preset given that monitor resolution can change so much, and this seems to not be a common setting to have changed by a preset. While I think that setting the resolution to 75% on my low performance reference laptop provided a good balance of increased performance for an acceptable loss of resolution, I am not confident that this is a tradeoff that enough players would agree with. I think it is still worth considering though.
The Low Performance Reference machine I used is a 2011 mid-range laptop, with an i5-2520m and Intel HD 3000 integrated graphics.
It ran the game at an acceptable fps throughout the game in the latest devbuild of 0.9, and its performance seemed to be similar enough to other computers mentioned on the Thrive forums that it is representative of the kind of low performance hardware that Thrive is played on. Also, the game seems to now be mostly free of lag spikes and stuttering, and so even when the game has a low fps it is consistent enough to be a smooth and playable experience.
This is the performance the game was getting at the suggested low performance preset settings across editor cycles 2-13, ending with multicellular. Cycle 13 is noticeably lower in fps, but this is due to having a particularly large amount of player cells clumping together, over 20, and so this represents the worst case multicellular fps. I also did testing in multicellular stage and the performance was closer to the previous 17fps average in microbe stage. There is another noticeable drop in performance at cycle 8.5, which is where I zoomed out the camera to maximum due to cycle 8 becoming a eukaryote, and it seems like most players zoom out the camera by now as the cell begins to fill the screen. At this point, typically 20-30 cells are visible on screen fully zoomed out.
All testing on this graph was done in the vents patch, but the tidepool patch seemed to have very similar performance on this machine when tested separately. Hhyyrylainen mentioned that the performance on his computer was much lower in the tidepool due to the particles, so this might be something to look into in the future as this difference was not seen on my machine using the latest devbuild.
Which upscaling mode did you use? On my low-end test machines I can only use like the bicubic filtering for upscaling as FSR 1 and FSR 2 add so much compute overhead that I’d need to crank down the resolution scale to like 30%, but using the simpler upscaling mode allowed me to have a more reasonable resolution scale at 70% and it still improved performance quite a bit.
So yeah, I also don’t know if low settings should have a resolution scale applied because we would need to pick a mode for it and on many low end devices they cannot handle the overhead of FSR (which looks way better than simple upscaling). But then on a little bit more powerful devices FSR 1 doesn’t really impact the framerate whatsoever. And of course then on a proper gaming GPU it doesn’t care if you even use FSR 2.
At least this is my assumption, because my Windows 10 computer has a GTX 1080 Ti in it, and that should still have way more graphics power than an integrated GPU, though it doesn’t have as new features anymore, which is why I’m guessing it experiences a problem. I don’t really have any other explanation than some particles, because when I played in the vents I got basically vsync locked to 144 FPS, but then moving to a surface patch, I only got 40-60 FPS (at best), which is a super weird performance dip.
So yeah, I want to add a graphics option to disable the current particles to be able to confirm if that’s the problem.
The OpenGL renderer can only support the Bilinear filtering, so that would have to be the default for that renderer anyway.
The oldest Vulkan Compatable integrated GPU I have that I could test out the different upscaling methods on would be a Surface Pro 3 i5 4300U, with HD Graphics 4400, from 2013. This particular system nearly requires the heavy resolution scaling due to the high resolution screen. I can test that out later if we are considering resolution scale on a preset any further.
I have a Windows 10 computer with a GTX 970 in it, which is similar era hardware, so I could also test out that machine if you need a comparison if your investigation of the performance difference between patches is inconclusive.
Oh right, I did not remember that. So it kind of would be possible to have a resolution preset for OpenGL mode, but like you said that might not actually help that much if people are pairing low end computers with low resolution screens anyway.
It turns out that the Intel 4000 series processors iGPU (Haswell) only supports Vulkan in Linux, and not Windows 10. Only 6000 series and up (Skylake) supports Vulkan in Windows unfortunately.
Anyway, it seems like the resolution scaling has broken on my Surface Pro 3 i5 4300U with HD Graphics 4400 machine, as it always drops performance significantly when enabled. Using OpenGL renderer on Windows 10 due to the Vulcan support lacking on Windows.
This occurs on the latest 0.9 devbuild, while the resolution scaling works fine on 0.8.3. I don’t think those settings would have been affected by anything other than the switch to the new Godot version?
It is kind of strange that it broke on this machine, while it worked fine on the previous generation of Intel iGPU on that same devbuild.
It might just be me, but when testing FSR 1, 2, and the simple bilinear on my main PC, I couldn’t really see much of a difference even at below 50% resolution scaling. FSR 1 looked nearly the same to me, and FSR2 was only slightly noticeable, but was not worth the performance cost even on my modern GPU. I think it is because the game has a lot of blurring effects, such as the chromatic aberration and others, that contribute to the output being quite soft. So I don’t think FSR 1 and 2 are especially useful on the microbe stages. (And I don’t think there is anything wrong with the microbe stage being soft, I think it looks right.)
I would suggest that having bilinear would be an acceptable default for the low resolution preset even when using Vulkan. And even if we don’t set the resolution scaling to lower than 100% with the preset, having bilinear be the default option would be better if the player does decide to change the resolution setting manually without testing the other settings.
Yeah, the update to Godot 4.5 is about the only thing I can think of that could have caused it. If you can figure out how to trigger the bug, there might still be time to report it to Godot for a 4.5.1 patch release which I think is coming pretty soon.
Interesting. I was testing with the 3D main menu backgrounds enabled, and there is a huge difference in the volcanic vents background in how good it looks, like bilinear filtering makes the foreground, well, ground look totally terrible with like 30-40% resolution scale, but FSR 2 is able to rescue the quality of those elements.
In my eyes the difference in quality is again so huge that we should not set a mode by default that is unnecessary on a reasonable gaming computer. So again I kind of think that these ultimate low end computer users will just have to know how to crank down all the settings, unless we have like a “very low” quality preset where we have truly put everything as low as they go.
