Before, all the ships were moving at exactly the same speed, making them appear
static on screen. Now, Chris is moving slowly to the right, but the WEAPCO
fighters are changing velocity now and then, both horizontally and vertically,
never quite reaching Chris but increasing their attempts.
When travelling between planets, while the progress bar was growing, it was
possible to click on planets, thereby changing the final destination planet.
The old technique was to overlay a semi-transparent red rectangle over an
existing ship image, and then make 50% red pixels transparent. For some reason,
the transparency is not working correctly. Instead, don't overlay anything,
but set the red component of all non-black pixels to the maximum value.
The code always tries to overwrite some data files when not using a .pak
file. This is only useful for upstream development. Put #ifdefs around
this code.
- We now have both minPlasma* and maxPlasma* variables.
- *PlasmaRate now goes from 1 to 5 just like Damage and Output.
- Internally, plasma now goes into the primary weapon, there is no
temporary weapon anymore.
- When upgrading the primary weapon, the new minimum amount of Damage,
Output and Rate immediately goes into effect when starting the next
msision.
- Super Charge now works exactly the same again as in the original.
- But shows blinkenlights in the bottom status bar when it is in use.
There were three flags, WF_STRAIGHT, WF_THIN_SPREAD and WF_WIDE_SPREAD,
when only one flag, WF_SPREAD suffices. This makes the code simpler and
gets rid of some duplication.
Put the maximum amount of rockets that can be caried in the description, and
also adjust the amount of rocket pods one has when buying a secondary weapon.
The laser and charge beam will remove all rocket capacity. To soften the blow,
you get at least capacity for 5 rockets when buying homing missile systems,
or 10 when buying normal missile system.
Before, if a value was over one of the limits, it would be set to the
other limit. For most usecases, that was fine, however for the starfield
this would cause stars to become aligned to each other after a while.
All functions and variables are now defined in graphics.cpp.
Before, the functions would be compiled again and again for every source
file, now it is compiled only once, halving the size of the stripped
starfighter binary.
There is no reason to have objects which contain only static functions
and no variables. These functions have been moved to the global
namespace and are now defined in .cpp files. The math functions are very
small and have been put in math.h and made static inline.
The state of these options was not only stored in the global config
file, but also in each saved game. When loading a game or clicking on
"continue game" from the title screen, the state of these options would
also be loaded from the save game file. If this changed the state of
sound and music, this would only take effect when starting a mission or
going back to the title screen. If it changed the state of the
fullscreen option, it would never toggle the state, but would
desynchronise the actual state of the window and the fullscreen option.
This is now fixed by moving these options from the currentGame variable
to the engine variable, where they are not in danger of being
overwritten.
Most .h files were not used to declare the externally visible variables
and functions of the .cpp files, but only to #include things and declare
things that were needed by that .cpp file itself. This resulted in a lot
of duplication.
Now the .h files only declare what is externally visible from the
corresponding .cpp files. Starfighter.h includes all the other .h files,
and all .cpp files only #include "Starfighter.h". Functions and
variables that were not used outside the .cpp file that contained them
were marked static. Variables defined in .h files were moved to the
appropriate .cpp files.
This fixes a bug where one could get more than half the item price back. In
particularly, a level 2 Plasma Cooling Booster would sell for more than you
bought it for.
This fixes Debian bug #253380.
During the game, a lot of images were blitted outside the visible area. Also,
addBuffer() was called even when the destination surface was not the screen,
resulting in unnecessary blits in unBuffer().
This increases efficiency significantly. Before, callgrind estimated that 58%
of the CPU time was spent in doInfo(), taking roughly 1.6 kcycles on average
per call. After, only 0.13 kcycles on average per call are used (12x speedup),
and only 14% of the CPU time is spent in doInfo().
Scrolling 1/4 pixel per frame results in jerky motion, mostly because 4
times 16 2/3 milliseconds is not a round number. Scrolling 1/3 pixel per
frame results in much smoother scrolling.
Guus Sliepen