This one's weird: it doesn't affect the actual generation of ASM in
the function, but rather it affects the ASM of sinf and cosf.
You see, sinf and cosf are static - they're built right into the EXE.
Since the previous code used cosf and sinf, they were embedded into
the EXE, and InitTriangleTable would call them directly.
However, this isn't what the original EXE does: instead,
InitTriangleTable calls an intermediary function, that in turn calls
the real cosf and sinf. Turns out this strange code generation is
caused by calling cos and sin instead of cosf and sinf, but still
using float parameters.
This is crazy. So, MSVC2003 always links the source files in
alphabetical order, but for some reason the original EXE ends with
the NPC and boss files.
Cucky figured out why: Pixel used folders in his Visual Studio
project - one for NPC code, and one for boss code.
With this, the built EXE now has its functions in the exact same
order as the original. Hell yeah. I guess now we just have to figure
out how to get the variables in the correct order.
All the broken stuff just happened to work on 32-bit, but would cause
MinGW-w64 to explode if you tried building as 64-bit.
I guess thanks to Microsoft keeping the basic C int types the same
size in 64-bit as they were in 32-bit, this branch compiles as 64-bit
just fine, despite Cave Story's many int-size dependencies.
32-bit MinGW-w64 has this stupid thing where the Makefile can't
detect that executable depedencies may end with '.exe', causing it to
regenerate them every time it's ran.
I really need to test thing before I commit them.
The library linkage things are because MinGW-w64 on Linux is
case-sensitive.
Unfortunately, Linux windres seems to have a problem with
Windows-style directory separators, so if you try building on Linux,
you'll have to convert CSE2.rc to use forward-slashes. I'd make a
commit that does this, but I'm pretty sure MSVC2003 will just revert
it automatically.
