If this is done within the intermission code, both intermission and menu will write to the same global variables and destroy their data, this became very apparent when it altered the screen scale for the conversation.
GCC 8 complains that it can't find relevant functions:
/wrkdirs/usr/ports/games/gzdoom/work/gzdoom-g3.7.2/src/m_png.cpp:669:42: error: call of overloaded 'BigLong(uint32_t)' is ambiguous
chunklen = BigLong((unsigned int)x[1]);
^
In file included from /wrkdirs/usr/ports/games/gzdoom/work/gzdoom-g3.7.2/src/m_png.cpp:44:
/wrkdirs/usr/ports/games/gzdoom/work/gzdoom-g3.7.2/src/m_swap.h:212:15: note: candidate: 'long unsigned int BigLong(long unsigned int)' <deleted>
unsigned long BigLong(unsigned long) = delete;
^~~~~~~
/wrkdirs/usr/ports/games/gzdoom/work/gzdoom-g3.7.2/src/m_swap.h:213:6: note: candidate: 'long int BigLong(long int)' <deleted>
long BigLong(long) = delete;
This is on FreeBSD/powerpc64.
The current menu system simply does not work that well with 320x200, rendering the game hard to use at that tiny screen size. This is a clear case where the work required to keep it operational stands in no relation to the benefit.
These can cause highly dangerous recursions and execute play code deep inside the renderer and since the hardware renderer does not have these, there is very little point for the software renderer to retain them.
src/rendering/vulkan/renderer/vk_renderpass.cpp:44:22: warning: comparison of integers of different signs: 'std::__1::vector<FVertexBufferAttribute, std::__1::allocator<FVertexBufferAttribute> >::size_type' (aka 'unsigned long') and 'int' [-Wsign-compare]
src/rendering/vulkan/system/vk_framebuffer.cpp:860:55: warning: format specifies type 'int' but the argument has type 'VkDeviceSize' (aka 'unsigned long long') [-Wformat]
src/rendering/vulkan/system/vk_objects.h:471:23: warning: suggest braces around initialization of subobject [-Wmissing-braces]
It should be said in no uncertain terms that OnRegister operates on an uninitialized level so it should only be used for setting up the registering process of the event handler itself and nothing else - not even the event handler's data!!!
Try to mimic OpenGL GPU selection behavior with MoltenVK when automated graphics switching is disabled
The CVAR isn't exposed in menu and its target audience is advanced users only
There are two options here - one only disables the vertical thrust and the other goes back fully to the original non-z-aware code.
Both options are settable through MAPINFO.
For the compatibility presets, the normal ones only disable the vertical thrust, the strict ones force use of the old code entirely.
This allows models to render, but a proper fix should handle mapping of static buffers for real. This workaround just allocates a non-static persistent buffer in CPU memory which is not the most efficient solution here.
