Japanese Bravely Second shows garbage as name under regionfree on US n3ds

[chaoskagami]

More specifically, the title shows up as "Ōì¤Ōêū»«óÉ" which is obviously not correct. I can't say what it shows up as on a japanese 3ds, unfortunately - but this is obviously a character encoding issue. My best guess is either a) the game is JIS and it's showing as UTF8 or b) formatting title as ascii when it shouldn't.

I notice in the regionfree.c file that no conversion of character set occurs, and the info struct is directly filled with a pointer offset. Are localized game titles handled correctly?

[yellows8]

Yeah it's just displaying the strings as ASCII basically atm, don't know what all characters this font includes.

[handsomematt]

Try #14 but we probably also need the various characters in the font too.

[chaoskagami]

I'll have to set up a cross-toolchain. I have an aversion to devkitpro, since I use a source-based system.

When I finish setting it up, I'll build PR#14 and report differences. Should I be using the master of ctrulib to build this, or a specific commit/tag?

[handsomematt]

master should compile fine.

[chaoskagami]

Good to know. Once crosstool-ng finishes bootstrapping GCC, I'll report back.

[profi200]

It simply does not support special characters yet. Only ASCII. No idea if anyone is working on fixing that.

[chaoskagami]

@profi200 No? Maybe I'll take a stab at getting gamecarts' titles working, then. Shouldn't be terribly hard. Just need to figure out what encoding I should convert from to display it.

Also, #14 allows smdh localization properly. It does not however apply cleanly on master and allow building. There's a few references to utils.h which is deleted by #14. Removing said references allows it all to build without issue.

EDIT - Actually, I'm not entirely sure whether it works right. I also have a few suggestions for #14, but I'll put those over there rather than here.

[chaoskagami]

Actually, even worse; #14 messes up titles of games which displayed perfectly fine without the patch. At least with cartridges; homebrew seems unaffected. Fire Emblem Awakening for example, shows up completely invalid.

Restarting tests on vanilla master, I set up the debug text to do a hexdump of the title, and I got exactly as I expected; the hex for the string above: "Ōì¤Ōêū»«óÉ".

I tested to see; JP/language=0 contains the same text as english, the above. All the above non-en non-jp languages just are zero-filled. Smash and others display as expected, multiple regioned titles.

I think that the title is getting butchered somehow at some point, or perhaps it isn't even being read correctly from the gamecard with this specific game for some reason. There's definitely amiss before the utf functions even convert strings. I'm not sure how to fix this. Any idea where the misbehavior actually is or how to even investigate it?

Not like it renders me unable to play, but it IS weird. Also, I registered it in streetpass and it shows 'BRAVELY SECOND' there, so it must have a valid title to have actually that set properly.

[chaoskagami]

Incidentally, the font only includes ASCII. No amount of localization will help with that. Furthermore, smea used Segoe UI as the base font. Which is bad. Being a microsoft font and all, it's not okay legally to use it like that, so I replaced it with liberation sans in my branch. I'll submit a PR for that, but it's not nearly as pretty.

Hopefully I'll figure out how to get all the extra glyphs in there soon. :<

[profi200]

I just said it's caused by the lack of UTF-8 support and a full font for it.

[chaoskagami]

I'm aware. I was just confirming that what you said was correct. Sorry if I came across too forceful or anything. Partially I was just rambling since the codebase isn't well documented, and I was trying to familarize myself with it while half asleep and low on caffiene. Sorry. :(

Anyways, the real problem is the drawCharacter function in text.c. The third parameter is the character to draw, and that's the problem. It could be fixed by replacing with wchar_ts, but that changes a good bit of logic and any strings that aren't wchar_t would have to be rewritten as such. I actually had to deobfuscate the code in text.c file to figure out what it did in the first place, but that's where the issue is.

[suloku]

Mashers is developing a font engine with utf8 support, word wrapping, any text color, etc, in fact he is doing it for his homebrew launcher mod.

[chaoskagami]

There's a lot of development going on for the 3ds now. It's a lot like the early days of the PSP, which is nice.

Anyways, I'm going to attempt to compile freetype for the 3ds and use that to do the font rendering - I imagine that would make all this work much easier. Guess I'm kinda doing my own thing now, and this bug report has gone way off topic. My fault, of course. ;P

[profi200]

There is sftdlib which uses freetype and does text drawing using the GPU.