28 Jun 23, 03:13PM
A little update,
sadly i have bad news, i found some more flaws within the game engine which will cause trouble with performance later on.
The first issue you already know by now, which are the world vertices, those however i managed to avoid mostly but not completly which therefore remain to be a bad impact on frames per second.
The second issue, i found out last days by adding the project (new map) into the game, which is no vram unload. What that means is, that the game will keep all textures stored in the vram even when playing on a different map, that however means that at a certain point we reach our max vram capacity (differs between systems) which then causes massive stutter/fps drops. The engine also goes to "reload" all textures when changing graphic settings.
This will mean that if a map uses 1 GB of Vram, we use 2GB upon second load. Using this knowledge and combine it with the fact that we want to increase texture size (which leads to higher vram usage) we quickly would go to lose people which could play on the map.
For that you have to know that for example 1000 textures of resolution 512x512 will be 1000 draw calls, those are processed by your CPU and since we´re only using one core we would have massive performance issues, if we however switch it around and would use 250 textures of 1024x1024 we have less load on the CPU but use more vram than most peoples GPU´s have, which would result in a pretty unused GPU in terms of clock rates but with maxed out vram causing the performance drop to nearly 0 fps.
Now adding the 2 found issues to those factors, we know that the graphics i aimed for is possible but would still require high hardware (much vram)
So technically it would run with 2000 fps on a gaming system with example. 8GB Vram but on a system with 512 MB vram it might even crash or would run with 0fps, while both systems CPU and GPU wouldnt be maxed out in terms of clock speeds, due to low poly meshes.
In other words, when baking light and shadows into textures i put the load to another direction and the idea was to put it on the CPU (since low hardware has minimal vram or only shared memory) This would have worked if the Game Engine would use multiple cores, or it still works to a certain degree, for example having 250 textures at 512x512 res. its still a problem since the game doesnt unload.
The end result is, we have to use a new engine otherwise we have nice graphics but making it unrunable for people on low hardware.
And there are some other issues which i dont wanna talk about public, since that information could be used for hackers advantage.
Wish i had better news. So hopefully the og developers still plan to move to a new engine (Not tesseract/cube2)
sadly i have bad news, i found some more flaws within the game engine which will cause trouble with performance later on.
The first issue you already know by now, which are the world vertices, those however i managed to avoid mostly but not completly which therefore remain to be a bad impact on frames per second.
The second issue, i found out last days by adding the project (new map) into the game, which is no vram unload. What that means is, that the game will keep all textures stored in the vram even when playing on a different map, that however means that at a certain point we reach our max vram capacity (differs between systems) which then causes massive stutter/fps drops. The engine also goes to "reload" all textures when changing graphic settings.
This will mean that if a map uses 1 GB of Vram, we use 2GB upon second load. Using this knowledge and combine it with the fact that we want to increase texture size (which leads to higher vram usage) we quickly would go to lose people which could play on the map.
For that you have to know that for example 1000 textures of resolution 512x512 will be 1000 draw calls, those are processed by your CPU and since we´re only using one core we would have massive performance issues, if we however switch it around and would use 250 textures of 1024x1024 we have less load on the CPU but use more vram than most peoples GPU´s have, which would result in a pretty unused GPU in terms of clock rates but with maxed out vram causing the performance drop to nearly 0 fps.
Now adding the 2 found issues to those factors, we know that the graphics i aimed for is possible but would still require high hardware (much vram)
So technically it would run with 2000 fps on a gaming system with example. 8GB Vram but on a system with 512 MB vram it might even crash or would run with 0fps, while both systems CPU and GPU wouldnt be maxed out in terms of clock speeds, due to low poly meshes.
In other words, when baking light and shadows into textures i put the load to another direction and the idea was to put it on the CPU (since low hardware has minimal vram or only shared memory) This would have worked if the Game Engine would use multiple cores, or it still works to a certain degree, for example having 250 textures at 512x512 res. its still a problem since the game doesnt unload.
The end result is, we have to use a new engine otherwise we have nice graphics but making it unrunable for people on low hardware.
And there are some other issues which i dont wanna talk about public, since that information could be used for hackers advantage.
Wish i had better news. So hopefully the og developers still plan to move to a new engine (Not tesseract/cube2)
