Things to do when (if) the Game API is broken anyway

[DanielGibson]

Since 1.5.0 I avoided breaking the API for Mod DLLs, so 1. Mods maintained externally (like librecoop) are compatible with all dhewm3 versions since then, and 2. I don't have to adjust all the mods that live in the dhewm3-sdk repo.

However, if it needs to be broken for some (good) reason, here's a list of things that could be done:

• Merge #369 which refactors the idGameEdit class
• CVarSystem.h: Make staticCVarsInvalid UINTPTR_MAX (so it's 0xFFFFFFFFFFFFFFFF on 64bit instead of 0xFFFFFFFF)
• Modify idStr to not waste space due to padding, and maybe increase its size from 40 bytes to 48 bytes (STR_ALLOC_BASE = 32) on 64bit
• Maybe make idList a proper dynamic array class that only creates objects when adding corresponding elements (allocate char buffer and use placement new instead of new T[size]) and destructs them when they're being "removed" from the idList
  • Need to make sure this doesn't break anything, maybe there's code that maybe assumes that allocated (but not officially "added") elements can be written to?
• Fix jointHandle_t typedef, so it's not just an enum with only one valid value (INVALID_JOINT = -1), but either a simple int, or a struct wrapping an int, making INVALID_JOINT = -1 an anonymous enum.
  • It is used like a normal int, so the current code is undefined behavior (but changing it breaks the game API).
  • typedef struct jointHandle_t { int jh; ... } jointHandle_t; looks like it'd work on Linux (x86/amd64; and possibly other OSs using System V ABI?), but definitely not on Windows (MSVC for X64, X86 or ARM, they all have different name mangling for functions taking it as an argument, and I think they also pass that struct vs the enum differently to called functions)
• Fix undefined behavior with bool and varargs in idCmdSystem::ArgCompletion_FolderExtension(): https://github.com/dhewm/dhewm3/pull/482
• Rendersystem_init.cpp: Turn g_screenshotFormat into a proper argument of idRenderSystem::TakeScreenshot()
• idRenderSystem should, in addition to GetScreenWidth()/Height(), have something that returns glconfig_t::winWidth/Height
• Make official Windows builds 64bit (32bit Windows isn't really relevant anymore)
  • though in theory, with potentially a lot of work that no one wants to do, it might be possible to create a wrapper game DLL that is able to load game DLLs from orig Doom3? That would most probably require 32bit builds though..
• TODO: add more to this list whenever I remember something