This is capable of handling any resolution which is at least 640x360.
Actually, resolutions a bit smaller than that can be handled. No
manual adjustment is necessary. :)
Now, the intermission screen needs to be fixed...
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).
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.
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.
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.
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.
I honestly don't understand why these cheats were here. Preventing
enemies from moving breaks some missions and doesn't do anything
useful, and preventing enemies from firing is basically no better
than the invincibility cheat (and might even be worse, if it applies
to Sid; I didn't check).
The way it was previously, you always knew exactly where the WEAPCO
scientist was. I don't remember if this was the case in the original
game (I don't think it was), but regardless, this makes the mission
seem incredibly short and easy, and it ends up centering on the
secondary objective rather than the primary objective. Now, you have
to search through all the asteroids until you find the right one,
and you have to pay close attention to explosions. Collecting ore is
just something you do along the way.
It may be fake difficulty, but after all, tropes are not bad.
The bug in question caused the super charge to be stripped away when
you collected powerups; each powerup would limit that aspect of your
weapon to its maximum. This put a limit on how long you could keep the
super charge, so I've added it back in for "original" difficulty.
There. Together with spreading out the asteroids, this has the effect
of getting rid of the sort of boxed-in feel this mission originally
had, and preventing the mission from being beaten simply by going
up or down forever.
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.
It previosly spawned half of the time. Now it spawns 4/5 of the time.
This makes waiting for it to show up so you can fight it a lot less
painful, even if it doesn't make a whole lot of sense.
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.