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...
This places the logo at 1/3 of the way down the screen, rather than
half of the way down, and the menu ends up about in the middle of
the screen now. This doesn't really matter as it is, but it should
help some with lower resolutions.
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.
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.
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).
This feature is just annoying if for some reason you want to leave
the game to do something else while you wait for something. That
would normally be a defect, but I can't count the number of times
I've been rushing through to get to a particular area, using cheats,
and had to wait for some mission condition, and this is only made
worse by not being able to do some other work while I wait for it.
This long-standing bug was caused by using blending when trying to
copy an image, though for some reason it was inconsistent. Thanks to
everyone on the SDL mailing list for helping me solve this one!
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.
I don't know why it was changed, but the changed version caused
full spread rather than partial spread with the triple shot, and it
also caused the quaduple shot to be arguably worse than the triple
shot.
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.
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.
I noticed that in "original" difficulty, plasma upgrades are basically
prohibitively expensive, which is not at all like the original. To
fix this, I've given that difficulty the original prices for those.
I've also slightly reduced the normal cost of permanent upgrades.
In particular:
* The charge cannon in that difficulty now behaves as originally.
* Cash is now rare, not nonexistent, on interceptions in that difficulty.
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.
Now, rather than powerups being replaced with ammo, their collection
effect has been changed from "make the plasma ammo at least 50" to
"add the powerup's amount to the plasma ammo" (i.e. powerups are also
treated as plasma ammo). This left the initial ammo of a powerup a
little low, so to compensate, I increased the collectValue of the
transport ship from 30 to 40.
Additionally, transport ships now show up in interceptions again,
but powerups, when collected, do *not* increase ammo. If you have
no ammo at the time, the powerup does nothing. If this happens with
the Super Charge, you get a humorous message.
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.
This change in behavior has some very significant effects:
1. Damaging a child alien isn't rendered meaningless if you are
primarily attacking the owner. This could be especially annoying
with the miner bosses, which have tiny parts that are completely
impractical to aim at.
2. Again, for the miner boss: previously, you couldn't see how much
total health the ship had; the health bar only uselessly showed
whether or not you defeated half of the ship (which you could
already tell by looking at it). Now, the health bar tells you
how much more damage you have to do in total.
As a result, you're not stuck with the weakest weapon in the game
anymore. You have to choose between the double rockets, plasma
permanently upgraded in one area, plasma temporarily upgraded in
some areas, or some combination.
This is silly. The libraries used have absolutely nothing to do with
"Linux". They're POSIX standard libraries, and will work just as
well on Mac OS X and BSD. The actual code might need to be replaced,
but in any case, this isn't something to limit to "Linux" systems.
The previous method was inconsistent between the left and right
directions; it placed the left edge of the bullet on the left edge of
the ship when going to the right, and in the center of the ship when
going left. This was barely noticeable with small ships, but more
noticeable with large ships. The method also sometimes made the backs
of bullets visible behind the smaller ships, which looked kind of
ugly.
Now, the back edge of the bullet is consistently placed in the center
of the ship.
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.
Started out adjusting prices, then ended up doing other things
while testing. Committing this now before I start doing other
random stuff!
But all of the changes are related to balancing difficulty, mostly
with prices, except for a couple bugfixes in the shop. Most notably:
* Ammo now costs $10, not $50. You no longer have to worry about
saving ammo quite as much as a result.
* Plasma upgrades' cost is now calculated differently, and the result
is slightly lower prices than before.
* Easy mode now grants the player more max ammo than other difficulties.
* Increasing max plasma ammo now costs less at the start, and increases
in cost faster.
* You increase max plasma ammo by 25 at a time, not 10. (10 was just too
small of a number.)
* Destroying enemy ships no longer gives you money. I found that, even
in hard mode, I had *way* too much money coming in, and this cuts it
down substantially. It also makes the shield bonus at the end of missions
much more significant. To compensate for the loss of massive bonuses
bosses used to give, these bosses now drop a lot more stuff.
* Kline has decreased health in his first encounter, and increased health
in his last two encounters (the numbers have been reversed).
Previously, when you bought something that took the place of something
you already had, such as buying a new secondary weapon, the old one
was just discarded. Now, it is sold, so you get money back for it
(the same as if you had manually sold everything).
* 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've tested this a lot, and I think these are good numbers to go by.
Plasma damage has been limited the most, because it is the upgrade
that quickly breaks the balance of the weapons, making the plasma
cannon the obviously most powerful weapon. I don't want this; the
powerful weapon should be the secondary weapon, while the plasma
cannon is the fast-firing weapon with much more ammo.
Basically, I want to make a tactic I found myself using, which was
to carefully keep my plasma power at maximum and take out most
enemies in one plasma shot, obsolete. As a result, missiles should
now be much more cost-effective (because even a single missile's
power of 15 greatly exceeds plasma's maximum power of 3*2=6).
None of these reductions in limits apply to easy mode; that mode
still has the old limits of 3 for min and 5 for max.
The way it was previously, it was tactically beneficial to ignore
temporary upgrades, if you were going to do a permanent upgrade to
that level anyway. This is silly. Now, you don't lose anything by
making the temporary upgrade first. You just get lesser access to
the upgrade earlier on.
I don't really understand why the original developer felt that
increased firing rate was so superior to the other upgrades as to
justify a far more inflated cost. Frankly, I find this upgrade to
be *inferior* to the power and output upgrades, for two reasons:
one, it doesn't increase the amount of damage inflicted per second
much; two, it increases plasma ammo usage as well, whereas the output
and power upgrades have no effect on plasma ammo usage. If anything,
firing rate upgrades should be *cheaper*, not more expensive!
This was inconsistent and had no particular benefits. The only minor
benefit I can see is that it prevents smaller enemies from hiding
inside bigger enemies, and in my test run through Spirit, this only
happened once. Not at all significant compared to how incredibly
awkward the aliens look when they're acting as if they can't move
through other ships.
This commit also includes more function name changes and other minor
style fixes.
3 damage? Really?! No wonder this weapon felt so weak compared to
the double rockets!
I've increased the damage to 7, which causes the total damage of the
weapon to be 35 (slightly more than the total damage of the double
rockets, which is 30).
I'm going to completely reorganize this absolute mess of a codebase.
First thing is to fix the names so that it's more obvious what files
they're defined in. Second thing is to move around some functions,
and rename some of the cpp and h files, to organize them better.
I'm doing these both at once.
I don't feel it's really necessary, and besides, it's annoying that
due to the way it's implemented it prevents you from doing anything
while it's shown.
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.
All gamepads I've come across work OK with button 2 or 3 as the primary
button, and button 1 or 4 as the secondary button. For the rest,
basically invariably, buttons 5 and 7 are the left shoulder buttons,
buttons 6 and 8 are the right shoulder buttons, button 9 is "Select"
or "Back", and button 10 is "Start". Based on this, I've changed
the gamepad controls to something that should work for most gamepads.
Also fixed some bad HTML in the documentation, and removed the
build instructions from there (they will soon be obsolete; I'm
working on replacing the hand-made Makefile with GNU Autoconf).
Using <SDL/SDL.h>, or in this case <SDL2/SDL.h>, and others like this
is not the proper way to include SDL headers. The proper way is to
pass the -lSDL2 flag to the compiler. The place I put it might be
awkward, but I'm planning to replace this hand-written makefile with
Autoconf/Automake scripts, anyway.
It's incredibly silly for it to be 10; what's the advantage of the
double homing missile launcher over the regular homing missile launcher
otherwise? It's just much slower and less versatile. Now it should
be slightly better, because you can effectively shoot 30 missiles
total, instead of just 20.
(Micro homing missiles are different; the advantage of having several
weak missiles instead of a smaller numer of strong missiles is
actually quite significant.)
There was a check that was supposed to prevent completing missions on
death, but it also prevented completing missions after an area was
finished. This was in particular a problem in interceptions, where
rescuing slaves after destroying interceptions didn't have any effect
on the slave rescue mission.
It was previously just ineffective. Now it's impossible.
The reason I'm doing this is when you *can* grind (in this case, by
constantly getting free plasma and selling it), it kind of feels
like an obligation to do so.
It's still possible to grind within missions whose progress depends
on your pace, which aren't timed and keep generating more enemies
until you win. Namely: the missile boat mission, the miner mission,
and the third boss. (There might be others.) However, grinding in
these situations is quite dangerous and likely to take away the much
larger shield bonus at the end, and plus if you mess up when trying
to do this you're set back quite a bit, so I think these are sufficiently
worthless activities that no one will do them. (I never did.)
A supercharge at this point can suddenly make bosses much easier
(especially the case with the Star Killer). This kind of takes away
the tension, so it's undesired. (It's fine for Easy difficulty,
because it's possible to take in a Supercharge from an earlier level
anyway.)
The original charge cannon is so overpowered it's ridiculous. The
strongest weapon in the game, unlimited ammo, and the only setback
it has is that you need to charge it a bit. The lack of balance
obsoletes the laser weapon, which is fine, but it also obsoletes
homing missile weapons, *including* ones that are newer and more
expensive than the charge cannon!
Now, it's much more balanced. You actually need to shoot the thing
before it hits max (or have your target in sight when it does),
rather than being able to just hold the button at max forever and
release when optimal like you previously could. Basically, the charge
cannon is still the weapon which does the most damage, but it's now
much harder to use. Incidentally, not only should homing missiles
be a sensible option now, even the laser cannon has a place after
the charge cannon becomes available.
In most cases, this has also resulted in limits being lifted. (The
only place I haven't done this is for planets in intermission.cpp,
but I think I'll take away that 10-planet limit as well.)
This is silly. I can see that someone decided to restrict targeting
to one ship as a difficulty setting, but that's not a very good way
to achieve different levels of difficulty.
Also added more music and slowed down RE.ogg.
So now, when currentGame.gamePlay is set to GAMEPLAY_ONPON:
- You start with 50 shield, and never gain any increased capacity.
- You can't charge the charge cannon and shoot at the same time; if
you shoot the plasma gun, the charge cannon shoots as well (as if
you had released the charge key).
I didn't add in the feature to keep the view from slowing you down,
because the method I used was imperfect anyway.
The source code contains routines to initialise all these resources, but also
functions to load from and store to external files. Support for external files
has now been removed; this removes a potential difference between compiling
with or without USEPAK, and makes it easier to change missions in the code.
onpon4
Guus Sliepen