Really not in the mood to deal with that damn mess. Maybe if the
bloody thing could be arsed to print an error or two, I'd know what's
wrong, but nope. Works fine on a regular MSYS2 installation, so sod
it.
These were retrieved from the Mac port (v0.0.7), which kept these
functions.
Unfortunately, this port is missing local variable names, so we can't
use it to make InitBack accurate.
This should prevent compilation errors when compilers don't read the
source files as UTF-8.
MSVC in certain codepages previously misread some UTF-8 comments as
containing newlines, causing it to try to process the rest of the
comment as code. This was fixed by forcing MSVC to read the files as
UTF-8 using the `/utf-8` flag, but this doesn't seem to be supported
in older versions.
Since the issue was caused by newlines being added where they didn't
belong, using C89-style comments instead should avoid the problem
altogether.
I'll still keep the utf-8 flag around for supported compilers - just
in case.
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).
Previously, it would misbehave if the screen is slightly wider than the level
(because it wasn't accounting for the fact that the game hides half of the
border tiles)
