By the way, I was testing out the GZDoom with OpenGLES API with all features active in the engine and all the mods that I am using. All features are maxxed out other than MSAA. If you look at the screenshot of the ZDL I managed to build, I definitely was using a lot of mods that covered everything from high resolution textures, lighting, shadows, 3d sprites, weather effects and etc. Yes, it rains, snows, ash falling and etc at times in my Doom. Lol The Pi 5 can definitely do quite a bit of justice in modernizing Doom even without Vulkan not actually working correctly in the engine. I did it with the "Best of Barbra Streisand" still playing on Youtube and everything on the screen still open. Even running all that while running GZDoom, the frame rate was still fine in game.
I did my build a little differently from this guide that allows a smaller size of the final executable and is specifically targeted for the Pi 5 system and build environment. It is actually simple to do this with this particular game as it is designed to be optimized as is using a straight cmake .. rather than cmake -DCMAKE_BUILD_TYPE=Release .. which will have you end up with fluff added to the executable. For this particular source, -DCMAKE_BUILD_TYPE=Release actually hurts optimization when running cmake. It is necessary with certain source, but the CMAKE file in the GZDoom git files already had the ability to automatically detect the build the environment. The CMAKE.txt was set to automatically provide O2 optimization in this build environment which is what we need with this OS environment for best performance. Adding -DCMAKE_BUILD_TYPE=Release may actually result in O3 (I provide an example of CXX flags from a CMAKE.TXT file below showing what RELEASE often results in) which is not considered optimum for this build environment. I didn't check though to see which optimization flag ended up used, but the executable I built is more than 20 megabytes less the executable you get following the instruction in this thread. Straight up cmake .. is all you need to generate a Makefile that is properly optimized if the source code is well programmed and meant to be multi platform.
Here is an example from a Cmake*.txt type file of how it usually works in most builds and why it is best to leave RELEASE out of it as a properly setup CMAKE*.txt will choose the best option based on your build environment in most cases. The CMAKE*.TXT will even show you the build options in many cases even when the source code has not build instructions. You can usually figure it out and end up with an optimum build with experience. This is why I love using a Pi because to get most of the better and more advanced games, you have to build source because they are often not in packages you can simply apt:
I did my build a little differently from this guide that allows a smaller size of the final executable and is specifically targeted for the Pi 5 system and build environment. It is actually simple to do this with this particular game as it is designed to be optimized as is using a straight cmake .. rather than cmake -DCMAKE_BUILD_TYPE=Release .. which will have you end up with fluff added to the executable. For this particular source, -DCMAKE_BUILD_TYPE=Release actually hurts optimization when running cmake. It is necessary with certain source, but the CMAKE file in the GZDoom git files already had the ability to automatically detect the build the environment. The CMAKE.txt was set to automatically provide O2 optimization in this build environment which is what we need with this OS environment for best performance. Adding -DCMAKE_BUILD_TYPE=Release may actually result in O3 (I provide an example of CXX flags from a CMAKE.TXT file below showing what RELEASE often results in) which is not considered optimum for this build environment. I didn't check though to see which optimization flag ended up used, but the executable I built is more than 20 megabytes less the executable you get following the instruction in this thread. Straight up cmake .. is all you need to generate a Makefile that is properly optimized if the source code is well programmed and meant to be multi platform.
Here is an example from a Cmake*.txt type file of how it usually works in most builds and why it is best to leave RELEASE out of it as a properly setup CMAKE*.txt will choose the best option based on your build environment in most cases. The CMAKE*.TXT will even show you the build options in many cases even when the source code has not build instructions. You can usually figure it out and end up with an optimum build with experience. This is why I love using a Pi because to get most of the better and more advanced games, you have to build source because they are often not in packages you can simply apt:
Code:
//Flags used by the CXX compiler during MINSIZEREL builds.CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG//Flags used by the CXX compiler during RELEASE builds.CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG//Flags used by the CXX compiler during RELWITHDEBINFO builds.CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUGStatistics: Posted by graphicw — Sun May 05, 2024 7:40 am