The plain int type is only guaranteed to be at least 16 bits, and
yet the flags variable was expecting at least 22 bits. This turns
out to be true for x86 and x86-64 systems, but to ensure compatibility,
the variable has been changed to an unsigned long int. Also added
the "L" suffix to flags that were more than 16 bits.
Most of these were defining various integers as char types, probably
in the naive belief that this is necessarily good because it uses less
RAM. There were also several unnecessary unsigned ints, though.
These have all been changed to just "int", so the compiler can decide
exactly what type to use.
This is mainly because the old "limit" functions were all restricted
to certain types, which is incredibly silly given how simple they are.
Macros are much simpler, and a warning gets raised if they're used
improperly with multiple types, anyway.
In the process, I also found and fixed a bug: it seems the original
author intended for escaping enemies to gradually accelerate to
fleeing speed, but the low value was indicated as the max value, and
the way limitFloat was written, that caused the max value to be used
(it was supposed to reduce the speed to a minimum of -15, but it
instead effectively assigned the speed to -15). It might be a good
idea to re-implement the old buggy behavior intentionally; depends
on whether the acceleration of jumping looks better or worse than
just immediately going to jump speed.
Kline previously had a maximum of 500 or 750 health, and uses some
hacks to cause it to flee just as it was destroyed, and to advance
to new stages in the final battle.
I've replaced this with a much larger amount of health, and progression
being based on how much health he has.
Also some other stuff.
* Modified the upgrade limits, to both be uniform and allow upgrades for
every factor. (In fact, each one can be upgraded exactly once now.)
* Gave triple-spread weapon double damage.
* Micro rocket damage down from 7 to 6. Total damage is now equal to
double rockets.
I found it kind of odd to be able to manually save to the autosave
slot, *and* have no reliable way to even know what the autosave
slot is. I noticed that it's an actual problem when my brothers
played Starfighter; one of them used an autosave slot, and the
other unwittingly ended up erasing the first one's save because of
this. To fix this, I have replaced the behavior of allowing the
player to define a slot as autosave, with a dedicated autosave
slot.
While I was there, I had no choice but to vastly improve on this
game's *atrocious* menu system. Granted, I didn't do much more
than replace the magic numbers with enums, but it makes the code
much more clear and more easy to edit.