Changed BalfrogAnims to BalfrogSprites
Changed BALFANI_[name] to BALFROG_SPRT_[name]
Changed -[macro](val) to [macro](-val)
Signed-off-by: Gabriel Ravier <gabravier@gmail.com>
I'm pretty sure Pixel didn't actually use macros for this but I don't think just having this kind of stuff copied around everywhere is really great either
Forgot to commit and push this yesterday
Signed-off-by: Gabriel Ravier <gabravier@gmail.com>
Also changed NPC_NULL_DELETES_ITSELF to NPC_DAMAGE_TEXT_HOLDER as Fayti pointed out the misnomer
Note to self : Make a PR with coding standards
Signed-off-by: Gabriel Ravier <gabravier@gmail.com>
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.
