The goal of the changes made in this PR is to create something with this
effect ("Jonko" is in in green, the rest is in white):
"Dear god." Jonko quickly replied,
crestfallen.
In order to do this, I need to call `NE_RichTextRender3D` or
`NE_RichTextRender3DAlpha` three times: once to draw the first part of
the sentence with the white font, once to draw "Jonko" in turquoise, and
once to draw the remainder of the sentence in white again. In order to
ensure that text is being drawn in the correct location, I need the
position where the previous call stopped drawing, which leads to the
first change this PR makes: I have added a version of
`DSF_StringRenderDryRun` which accepts pointers to `final_x` and
`final_y` and stores the last position of `font->pointer_x` and
`font->pointer_y` in them and I have added a new variant of
`NE_RichTextRenderDryRun` called `NE_RichTextRenderDryRunWithPos` which
uses that DSF function and has analogous parameters.
These functions get us the position where we need to place the next
cursor, but the next issue is that currently NitroEngine and libDSF only
allow for specifying the position of the overall box to draw text in,
but not where to offset the cursor in that box. This leads to the
following problem ("Jonko" is in in green, the rest is in white):
"Dear god." Jonko quickly replied,
crestfallen.
Thus, the second change: I have introduced new versions of
`DSF_StringRender3D` and `DSF_StringRender3DAlpha` which accept an
`xStart` position that is added to the `pointerX`. Correspondingly, I
have added versions of `NE_RichTextRender3D` and
`NE_RichTextRender3DAlpha` that use these new functions as well.
Let me know if there are any issues with how I've written this (C is not
my forte, after all), but the first screenshot is this being tested in
production code.
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.
