They were never meant to be there, they are a copy-paste error from taking
the code of the original text system to create the original files of the
rich text system.
Using g++ to link object files automatically links the STD of C++. It looks
like this library is linked outside of the start/end-group commands with
the other libraries, which causes undefined reference errors when linking
C++ projects that use standard library functions that interface with the
OS, like `fopen()`.
Thanks to @lifehackerhansol for the report and testing the fix.
This allows you to use one single texture for multiple images, and to
specify the coordinates that a sprite needs to use so that you don't need
to keep track of them.
Using `mulf32()` while compiling functions to Thumb makes the compiler
add calls to `__aeabi_lmul()` once per multiplication. This routine is
quite slow, so the cost of any function that uses `mulf32()` a lot is
quite high.
Switching math-heavy functions to ARM increases performance and reduces
code size.
Using global variables is generally discouraged. Now that NE_ProcessArg()
and NE_ProcessDualArg() exist, it's better to show how to use them instead
of NE_Process() and NE_ProcessDual() while using global variables.
Also, switch from "int main(void)" to "int main(int argc, char *argv[])".
Currently, if the user wants to load a GRF file with a palette, the
function NE_MaterialTexLoadGRF() will fail unless it is provided a palette
object.
With this change, if a palette object isn't provided, it will be created
and marked for automatic deletion when the material is deleted.
In many cases the developer doesn't want to keep track of palettes and
materials as two different objects. This is only required if a palette
needs to be shared between multiple materials.
In cases where there a palette is only used by one material, this new
function can be used so that the developer doesn't need to keep track of
the palette object, only the material.
When using dual 3D DMA mode the console is setup to use memory in the
middle of SUB background VRAM. This is what holds the text that you can see
on the screen.
When switching to FB mode, the console is never reconfigured (when
switching to regular dual 3D mode it is reconfigured). This means that any
printf will write to the middle of background VRAM, which is used as
framebuffer. This will manifest itself as a blue horizontal line in the
middle of the screen.
This patch fixes the examples to not print text when using FB mode.
Instead of allocating the buffer permanently, only allocate it while the
sprites are setup. Then, free the buffer.
Also, the cache needs to be flushed before doing a DMA copy. This used to
cause black squares on the screen because of some sprite attributes not
being properly copied to OAM.
