This switches the rich text library from using a constant for the max
number of fonts to allowing the user to specify how many fonts should be
used dynamically. To accomplish this, a new method is introduced to the
rich text system: `NE_RichTextStartSystem`, which accepts the number of
slots to allocate. Those slots are allocated and then freed when
`NE_RichTextResetSystem` is called.
To maintain compatibility, I have not removed `NE_MAX_RICH_TEXT_FONTS`
(instead opting to mark it as deprecated), and have added functionality
to automatically call `NE_RichTextStartSystem` with that old value (8)
if the user decides to init a rich text slot before calling
`NE_RichTextStartSystem` (which would likely be the previous default
behavior).
Nitro Engine doesn't work with the current libraries of devkitARM. It's
better to remove the makefiles and to stop pretending that devkitARM is
supported. Updating the makefiles wouldn't be enough, though, it's likely
that the library will require code changes, as well as the examples.
This texture format sets bit 15 manually to 1. This is slow, and it's
better if the developer converts graphics in a way that the bit is already
set to 1.
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.