Now the SDLSurface backend survives window resizes (also triggered by
alt-tabbing while in fullscreen), and the SDLTexture backend properly
regenerates its textures after a fullscreen alt-tab in DirectX mode.
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.
Previous, I used a godawful hack to emulate Windows' API, but it
seems this only ever worked for Courier New: with something like
Liberation Mono, it would squash the font. Now I'm just giving up on
it, and using actual font sizes rather than "cell" sizes.
I'm not sure if this is accurate the original EXE.
