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.
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.
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.
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[])".
Instead of having a different set of functions for each dual 3D mode,
have one set of functions that is clever enough to select the right code
to run based on the initialization function.
This change is a bit pedantic, but it makes the ROMs run better in
DeSmuMe.
Some examples (particularly the dual 3D examples) used to flicker during
one or two seconds right after starting. In dual 3D examples the top and
bottom screen would start swapped, and they would eventually swap and
stop flickering. This would never happen in melonDS or real hardware.
I suspect this is because of the interaction between GFX_FLUSH and
swiWaitForVBlank(), where there would be some timing difference to reach
the first swiWaitForVBlank() or GFX_FLUSH, and that caused the desync.
This commit moves swiWaitForVBlank() to the beginning of the game loop.
This means that, even in the first iteration of the game loop, all
emulators and hardware will be synchronized. This doesn't actually
matter in any other situation, it just makes the first iteration
consistent.
Yes, this is a bad idea, but there is no other way to easily build all
examples in one go. I will eventually improve the organization of this
example so that this step is done automatically during the build.
