Also, now that the magic numbers are gone, I was able to get rid of
all the hardsetting of numbers for the special ship indexes (which
was only in place to avoid breaking the magic numbers).
This name is better since the difficulty isn't actually *exactly*
like the original; it's just trying to be as similar to the classic
experience as possible.
Like "scripts", these definitions in text files make absolutely no
sense. They are completely unreadable, and Starfighter's engine is
inflexible anyway.
I'm going to do this for all of the stuff in the "data" directory.
It was obviously an attempt to make Starfighter more flexible
somehow, but it fails at that entirely. More importantly, these
things are both unreadable and easy to make mistakes on. Simple
C code is much easier to read.
The only disadvantage is that recompiling is now needed to change
the "scripts", but considering that they had hidden limits and
no one was making custom missions to begin with, I don't consider
this to be a real loss.
To my recollection, actually, this bug has *always* been present.
At first, I fixed it (the problem was the entry in script13.txt
was malformed), but when I did that, it caused the objective of
destroying Ursula's ship to be considered completed. In other words,
the game doesn't even have code to handle this as a failure
condition! So I've decided to remove it instead. It wasn't that
great of an idea, anyway.
I rewrote the method because what it was doing was so confusing, I
couldn't figure out whether it actually worked right or not. I think
it did, and it's only 2/3 of a milllisecond anyway (not noticeable
at all), but this new way of writing it is much clearer.
It wasn't very useful. All it did was offer the option to center
text and take away the option to wrap text. I've moved the text
centering option to gfx_renderString and replaced all uses of this
function with that function.
The fourth is simply a duplicate of ship_collision for bullets. A
bit redundant, but I figure it's clearer of a definition. Besides,
this opens up the door to possibly making bullets a different struct
type in the future, if that turns out to be desirable.
Starfighter uses an absurdly crude method for wrapping text which
basically fails very frequently when large words are chosen. The only
reason it got away with it is because text strings don't vary. Well,
I've been quite annoyed by having to test for this and rework my
text so much, so I've added in a secondary system: if it's really
close to the edge, and the next three characters are going to be
letters, it adds a hyphen and moves on to the next line. This still
isn't 100% fool-proof, but it should catch most problems.
Also removed the "temp fix" which shifted the letters by a pixel in
code, and just shifted them in the actual image. I don't understand
why the "temp fix" was there in the first place, to be honest.
The idea is clearly supposed to be breaking the boss in two and then
destroying the halves, so it makes no sense for the wings you break
off to also act as shields, which they did. Pretty much all this did
was cause a lot of shots to be wasted.
I don't really understand why this code was implemented only for the
boss and not for anyone else. My only guess is it was designed to make
the level harder by letting enemies fire backwards while you can't,
but mine-droppers can already effectively do that.
The primary reason I decided to make sure they all face forward is I
was finding it to be nearly impossible to get through this level in
Nightmare difficulty; those ships being able to shoot backwards is
a HUGE advantage, because it's almost impossible to position yourself
in an area that's safe.
It may be that the unfair previous behavior was put in to compensate
for the AI's frankly asinine movement pattern. The random movement is
fine most places, but here, it's blatantly obvious that it's random,
and the enemy ships pay a steep price for it. What the ships should
be doing is positioning themselves so that they end up shooting or
dropping mines at the player. But the boss itself also has such a
positioning problem anyway; that should be properly fixed in the
future, so I might as well do the same for the smaller ships when
that time comes.
onpon4