Variant of GL1, meant for embedded/mobile devices only.
Build it with "make with_gles1".
For Windows, you'll need MSYS2 and a decent ANGLE implementation
(probably not worth the trouble).
Building with CMake only works in Linux, so it has been commented out.
Implemented a batching procedure, to try to group meshes in a buffer
and use a final GL call to draw them all in one step, instead of the
many GL draw calls existing today.
For now, only 2D textures are included, especifically console text
("conchars"), scrap and tiles. It's not worth doing this for
individual 2D elements (e.g. crosshair).
This is hidden behind WITH_SDL3, which is disabled by default.
Additionally rename the SDL sources files in the client to represent the
SDL major version they are supporting. They will be forked for SDL 3.
That isn't optimal, because it forces us to support two variants of the
same code. However the changes between SDL 2 and 3 are too big to work
with #ifdef and something like function pointer magic is even more
confusing.
This matches the behavior of cmake. Besides that we have some optional
C11 code and it should be used if the compiler has support for it. And
C99 as default is a remnant from the old times were we didn't want C11
in the standard code path, because several old Linux distros didn't
support it...
This ensures that we call ARM64 `aarch64` on all platform, which aren't
MacOS or Windows. And it fixes the bug, that `arm64` was normalized to
`arm`, making incompatible savegames between 32 bit and 64 bit ARM
loadable. Leading to crashes.
At least for LLVM / Clang the -fsanitize= option must be passed to the
linker before any objects or libraries, otherwise the sanitizers will
either noch link or are disfunctional. Split LDFLAGS into LDFLAGS for
flags and LDLIBS for librariers, pass LDFLAGS before any objects and
LDLIBS after all objects. While at it set RTLD_NODELETE so that shared
libs opened by dlopen() are never deleted from memory when building
with sanitizers.
While this shouldn't be a problem with C code, better be safe than
sorry. @DanielGibson stumbled over this while debugging some strange
RB-Doom3 / dhewm3 issues with gcc. See this bug report for details:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
$PROCESSOR_ARCHITECTURE seems to contain the architecture of the host,
but we need the architecture the current MinGW shell is targeting.
$MINGW_CHOST seems to be just that, and on my system it's either
i686-w64-mingw32 (mingw32.exe) or x86_64-w64-mingw32 (mingw64.exe)
(No idea what it looks like for Windows on ARM...)
As fixing this would otherwise break existing savegames, I bumped the
SAVEGAMEVER to "YQ2-4" and added a quirk for older savegameversions:
On Windows i386 savegames that contain "AMD64" instead of "i386" as
architecture are also accepted.
(For YQ2-1 this didn't seem necessary, apparently "i386" was hardcoded)
* No need for global CXXFLAGS. The only difference to CFLAGS is the
standard selector, use $(subst) to derive them from CFLAGS.
* libstd++ must never be manually linked. Doing so only works for the
GNU C++ stack, not for the LLVM stack and anything else. Link with
the C++ frontend instead.
* Force MingW to g++ as CXX.Force MingW to g++ as CXX.
* No need to specify -lm, libm is already part of the global LDFLAGS.
* Windows doesn't need -fPIC.
* The Vulkan renderer doesn't use glad.
This is an enhancement to the previous `yield` work:
* Don't enforce `-march=armv8-a` for aarch64 builds, because it is the
initial ARMv8 revision and compilers will either use that or something
newer.
* Refine preprocessor guards around `asm("yield");` so the code isn't
compiled in if unsupported by the current `-march='.
Submitted by @smcv in #535.
