I've gotten better with MIPS and the debugger and finally am starting to find ways to affect the spacing, but it doesn't seem like I'll be able to do it without hardcoding, or at least loading my own code... as soon as I figure that out.Yeah, asm can be tricky to follow sometimes.
Hard to give specific advice but the breakpoints and adding conditions to them can be very useful.
Also a bit obvious but reading up on a mips32 reference should help, though you've probably done some of that.
The game recognizes full-width English via SHIFT-JIS, but that's it. Half-width doesn't crash the game, but the characters won't show up.I would guess that encoding implementations are specific to the game, with the exception that some games use the sce syscalls which presumably have expected input formats.
Edit: I would advise testing with English text in place to get a proper idea of what it will be like, and also for some games the routines used vary for English chars.
I'm not sure if this is the glyph table but I found it in EBOOT.BIN:a lot of games generally accept ascii inputs as it is (even if the font is not present for them)
there are easy ways to test this really, you type in some text, see if the game crashes,
then you change the glyph table to include the ascii symbols if they're omitted (padded with 0x00 to make it "2 bytes") and test again.
the most common reason for games to freeze/crash when unicode/UTF-8/whatever the japanese text is written as is replaced with ascii text is simply the matter that the glyph table doesnt have the characters for them.
i made the mistake once that i worked through a translation by encoding the text to FULLWIDTH instead of patching in a proper ascii routine, and while that does work per-se, it's really something you do not want to do, take my word on that.
as for your question, the encode type strings you see on your picture there are generally present on most games, stemming from the fact that psp uses system fonts/modules for printing some text that is present in the game data itself (sceImpose modules) this leads to the fact that since said system text is present on virtually every game, and it all conforms to the same thing, these strings can generally be located from any game.
while lots of games do use them for their own shit, it's not a given. even if you find these encoding tags from the code, nothing says the game isnt just doing it's own thing for actual input text.
Hi, I'm back at it. I know a lot more Japanese, but unfortunately not much more about ASM or coding. I do have an idea of what to do based on my last post though.
What I want to know is if it's possible to write my own code that would take single-byte ASCII, convert it to its double-byte Shift-JIS equivalent, then pass it back to the game's text handling routine. Still don't really have a good handle of ASM or writing my own code, but theoretically I could jump to my own code, then jump back to the game's, right?
So using this approach and some rudimentary and arbitrary ASM code of my own, I managed to do a quick conversion of ASCII to Shift-JIS, after I found and edited the instruction that handles taking two bytes for Shift-JIS instead of one for ASCII. The problems now are the conversion not applying to the player character's name, as well as the second line of text not continuing from the first.As far as converting I don't know the specifics of this one, however
http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml
In normal ASCII it is noted that numbers are 3 followed by the number you want, and more importantly for this then any lower case letters are 20h more than their upper case letters ( https://www.ascii-code.com/ ). That is to say add 20h and you have your value. Whether you could do something similar, or might need to break it down to ranges and adding different values accordingly I don't know offhand and am too lazy to figure it out here (most would either adapt the code, adapt the encoding, encode all their text in a suitable format -- barring memory issues it is not like the PSP is limited on space, especially not for text).
*if it is a simple addition then you can possibly do that in line/no jumps necessary, and if you somehow do have to jump to somewhere else you will not need to push and pop all the registers if you can get away with basically nothing.