This commit customises the software renderer specifically for the
3DS, taking into account its rotated framebuffer and BGR format.
With this, the game appears to run full-speed on Old3DSs. Of course,
the level transition effect still makes the console chug, but that
thing was always a bit of a bottleneck.
For whatever reason, the 3DS *really* doesn't like it when I do all
the audio mixing in the callback function. Instead, it seems I have
to use a dedicated thread.
On the 3DS, I want the data files to go in the read-only ROMFS, while
save data goes on the SD card. This is impossible with the current
system, so I'm changing it.
The other backends will need updating to support this.
Was a lot easier than I expected. The software renderer is such a
godsend for quick-and-dirty ports.
Oddly enough, even on an old3DS, this actually almost runs at full
speed (hits around 40FPS in Mimiga Village).
There's a lot of work left to do before this is actually useable:
* There's no audio
* You can't save
* A proper hardware-accelerated renderer is needed
With the new Wii U upscaling code, 640x480 uses too much MEM1.
Honestly, maybe I should just overhaul how render targets work on the
Wii U. Surely there's a way to dynamically allocate only one colour
buffer at a time?
This is in preparation for an upscaled-framebuffer system like the
OpenGL backend has.
I wonder if it's possible to just use a shader instead, and avoid the
need for an upscaled framebuffer to make the linear filtering not
look terrible.
This is accurate to the original EXE, which would default to CP1252
depending on what region Windows was set to. This is the case for
English and Spanish regions, and likely others.
This should make this branch compatible with a number of fan-made
translations. However, this also makes it so that the `PutText`
functions will no longer support UTF-8 strings.
Modders may prefer to switch to UTF-8 entirely, so I've left the old
UTF-8 parsing function in a comment.
