hu_stuff.h defined some callbacks for qsort without STACK_ARGS which causes problems with this solution's Release setting which uses __fastcall calling convention.
- fixed a CMake warning about uninitialized use of the variable CROSS_EXPORTS in the tools subfolder when CMAKE_CROSSCOMPILING is off;
- fixed a variable typo: CMAKE_CURRENTY_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR;
- in src/CMakeLists.txt, fixed a missing merge of a portion of code from maint branch to master.
Due to the way the engine works it needs to render a lot of small primitives with frequent state changes.
But due to the performance of buffer uploads it is impossible to upload each primitive's vertices to a buffer separately because buffer uploads nearly always stall the GPU.
On the other hand, in order to reduce the amount of buffer uploads all the necessary state changes would have to be saved in an array until they can finally be used. This method also imposed an unacceptable overhead.
Fortunately, uploading uniform arrays is very fast and doesn't cause GPU stalls, so now the engine puts the vertex data per primitive into a uniform array and uses a static vertex buffer to index the array in the vertex shader.
This method offers the same performance as immediate mode but only uses core profile features.
LZMA SDK recently added an #include <windows.h> to its headers, meaning it's no longer safe to include its headers globally in platform independent files.
The following changes were necessary:
- rename DWORD type in zipdir.c
- add USE_WINDOWS_DWORD and reorder includes in file_7z.cpp
- wrap LZMA decoder stream into a local struct that's declared anonymously in files.h and adjust files.cpp for this change.
Introduce the variable 'ZD_CMAKE_COMPILER_IS_GNUC(XX)_COMPATIBLE' and replace any occurrence of '"${CMAKE_C(XX)_COMPILER_ID}" STREQUAL "GNU" OR "${CMAKE_C(XX)_COMPILER_ID}" STREQUAL "Clang"' with it. This makes it possible to add more GCC compatible compilers in just one place.
The sdl version of the function 'SetLanguageIDs' is very limited, comparing to the win32 counterpart, as it will try to accept only the language codes (ie 'enu', 'fr', 'ptb', etc). If a different string is provided, zdoom will default its language to English.
After thinking about it for a day or so I believe it's the best option to remove all compatibility code because it's a major obstacle for a transition to a core profile.
