Some textures cannot be used in their current form, and so they are
transformed at build time by Imagemagick commands (e.g., add shapes,
crop and merge different portions, etc.).
For a very small number of textures, making them usable takes more than
a few simple commands. For example, Chell's eyes and ears are detached
from her face in the texture image, and there are not enough polygons in
her model or pixels in an N64 texture to make a good UV map.
For these few complex textures, James worked around the problem by
checking in pre-edited images. This commit removes those images and
instead performs the necessary transformations at build time. As a result,
some textures are now slightly different (ball launcher/catcher, cube,
Chell). Chell's UV map is redone to accomodate this - for the better.
* Do not include execinfo / backtrace (should implement Windows
equivalent in the future)
* Define YAML_CPP_STATIC_DEFINE, which should have been set anyway
We use the 6102 boot code by default, but this can be changed (for
example, if flashing to a cartridge with a different CIC).
As with the microcode, the path cannot be easily passed to the
linker script and so the hard-coded name should not be specific to
particular boot code.
Environment variable N64_ROOT optionally sets the root directory of
the N64 toolchain.
To enable this to work with the linker script, the microcode object
files are now copied to the build directory before linking (since
there is no easy way to pass the path to the script dynamically).
An added benefit to this approach is that different microcode can
now be used easily if desired.
With the implementation of save file deletion, I refactored
savefileNew() to re-use the common save file deletion code.
However, savefileDeleteGame() has the side effect of writing
the save back to SRAM. Since the rest of savefileNew() does
not write to SRAM, this means that on first boot it was
possible to get a partially-written save file if the game
was powered off before the first real save (some options had
zero/null values).
To fix this, I created a helper function to update a save file
in memory without writing it back to SRAM. This has the added
benefit of not unnecessarily re-ordering the slots in savefileNew().
I chose not to add a savefileSave() to the end of savefileNew()
since it is called from savefileLoad(), and saving while loading
doesn't seem intuitive. I also don't think it's a good idea to save
in the middle of initialization, in case a user is able to cut
power at the (im)perfect time. The operation should be atomic.