Until now the main makefiles of Nitro Engine have been the ones of
devkitPro, forcing users to go through extra steps to build everything
under BlocksDS.
Now, the easy makefiles are the BlocksDS ones, and additional notes have
been added to warn about the limitations of devkitPro:
- No GRF support in libnds.
- NitroFS doesn't work in melonDS.
This reverts commit 48ff37231f ("library: Remove unimplemented
functions from RichText system").
I thought the 3D drawing functions took a "depth" argument, but I was
wrong. I'm re-introducing the functions (and, this time, with an actual
implementation).
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.
