The CMake file allows you to compile the accurate branch with
whatever version of Visual Studio you have lying around, without
having to clumbsily convert the VS2003 project.
I've tested this with VS2019, VS2003, and VS6. VS6 is goofy - it's
missing a few types and constants, and it's not smart enough to
realise that ints and longs are the same in ILP32 data models. I've
added a few small hacks to address this. Might undo them. Who knows.
For now, I want to support VS6 because Mint compiled CSE2 with it
before, and because VS6 uses `msvcrt.dll` as its C runtime, which
apparently comes pre-installed in Windows, as opposed to all those
other annoying runtime versions that require they be installed
separately (which is why MinGW targets it specifically).
Also, VS6 *should* give us Win95-compatible builds. The internet says
MSVC2003 is Win95-compatible too, but Mint claims the vanilla EXE
doesn't run on there. I imagine it has something to do with its
static runtime library (VS2003 links the static one by default for
some reason).
This way, I can use immediate mode, which is way faster than using
buffers for some reason. Since I'm not using profiles anymore, I
dropped the minimum requirement to OpenGL 3.1. If a driver doesn't
support Legacy GL, then it can use the slow buffer code.
But seriously, I need to figure out why using buffers is so slow.
If this was a common problem, Modern OpenGL wouldn't have made it the
only option.
Yay 100% hardware-acceleration. Yes, I know 2.1 is outdated and
crappy, but it was the easiest one to write. I'll probably make an
OpenGL 3.0 Core renderer at some point.
Anyway, font rendering isn't here yet, because I plan to overhaul it.
Now the Makefile and CMake build systems are identical:
Release builds are named CSE2, and debug builds are named CSE2d.
Language no longer has an effect on filename for the Makefile.
It's annoying, but vcpkg *really* didn't agree with it (it would just
build Debug anyway). The instructions provided with the repo already
tell you to manually define Release builds anyway.
The Linux port's get_resource function seems to be using the original
filenames, rather than the 8.3 filenames used by the Windows EXE's
resource system. Too bad it doesn't tell us the original file extensions.
This forces CMake to use the local libraries, even if system libs
are readily available. This is useful for MSYS2, since find_package
would link dynamic libraries, but local libraries are static.
I'm taking a page from Dolphin's book, and including copies of each
dependency's source code. This combines the ease of use of including
pre-built libraries instead of needing to navigate a package manager
- as is (or was) the case for MSVC - with the portability of using
packages. Granted, this method's more of a jack of all trades,
master of none, since it's *less* user-friendly than prebuilt
packages (compilation times), and you don't get the per-distro
compatibility fixes you'd get from a package manager.
You can still use system libs if you want. In fact, it's still the
default behaviour: compiling the libs manually is just a fallback.
I'll add an option to force-enable this soon, however, since it's a
nicer way to produce static MSYS2 builds than the hackish nightmare
that I was using before. Not to mention, having my own copy of the
sources means I can provide my own fixes and tweaks your package
manager may not. For example, I can combine MSYS2's FreeType
subpixel rendering with vcpkg's fix for SDL2 exporting its symbols
in static builds.
