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.
Looking through the EBOOT.BIN, I saw that the game references four different font encodings:
Is there a significance to this with regards to how the game decides which font encodings to accept, or is this present in most PSP games? Basically, I'm trying to see where I'm headed after I'm satisfied with how the text is spaced.
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.
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.
Last edited by JamRules,
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.
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.
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'm not sure if this is the glyph table but I found it in EBOOT.BIN:
Just to test things out, I replaced the full-width English characters with standard ASCII plus the padded byte. Checking the main character name input screen, all I managed to do was remove the full-width English characters. At the same time, it still loaded full-width English characters I put in elsewhere.
I'm thinking the game is either loading text from somewhere else or is doing its own thing. I'm gonna keep looking for text.
I haven't given up but I have been a little busy lately.
I realized that I've only been tackling how to address spacing issues/fixes and not so much how the game takes the character it needs to draw and grabs it from the font sheets accordingly.
In this instance, the game is preparing to draw "こ" ("ko"). The game loads the part of the font sheet with the character on it (e5eac0). Where I get lost is how the game knows that in order to draw this character, it needs U values of c6 (from NOP: data= 0000c6) and d8 (from NOP: data= d8ffff) in addition to constant V values of 00 and 12 (16 pixels, half the height of the texture sheet). That's what I'm investigating now.
Just wanted to let people know I'm not dead lol but any hints are appreciated. Has anyone tried to translate this one before?
I realized that I've only been tackling how to address spacing issues/fixes and not so much how the game takes the character it needs to draw and grabs it from the font sheets accordingly.
Just wanted to let people know I'm not dead lol but any hints are appreciated. Has anyone tried to translate this one before?
Attachments
I think I've found the glyph coordinate routine.
At 088B480C, v1 becomes 00008371, which corresponds to "ヒ" in Shift-JIS, this kana being the first letter in the main character's name. The next time this routine is run, it loads 8385 for "ュ", the second letter, and so on. Later on in this function, the first U value for the glyph coordinate is loaded into s2, so I'm pretty sure I've found exactly what I've been looking for. How these values are derived from shift-JIS bytes is another story...
At 088B480C, v1 becomes 00008371, which corresponds to "ヒ" in Shift-JIS, this kana being the first letter in the main character's name. The next time this routine is run, it loads 8385 for "ュ", the second letter, and so on. Later on in this function, the first U value for the glyph coordinate is loaded into s2, so I'm pretty sure I've found exactly what I've been looking for. How these values are derived from shift-JIS bytes is another story...
Not sure if I would call this much of an update, but I haven't given up on translating just yet. Building on what I was looking into in the previous post, I believe I have a general idea of how this game handles text. Basically, the text routine expects two-byte Shift-JIS characters and uses each byte to determine the correct font sheet texture as well as glyph coordinates. I experimented with this by replacing text in the options menu with one-byte English and followed how the game handled this in the GE debugger. It actually comes up with the address for a font sheet and coordinates, but fails to print because the texture doesn't exist. I don't exactly know how it comes up with the font sheet and coordinates using those two Shift-JIS bytes, so I need to look at it more, but I'm wondering if it's possible to do something like:
- Change the entire text routine so it uses single-byte characters.
- Use this one byte to determine which texture and coordinates are needed.
- Print each character that way.
This changes the "encoding" of the font. Font width is definitely hard-coded, so I think a variable-width font would have to come after.
- Change the entire text routine so it uses single-byte characters.
- Use this one byte to determine which texture and coordinates are needed.
- Print each character that way.
This changes the "encoding" of the font. Font width is definitely hard-coded, so I think a variable-width font would have to come after.
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?
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?
Depending upon where you are in the code then jumping can be a bit tricky; the reason you are generally told not to call a function within a function is because processors only tend to keep the one return location in the register (don't know what it is called in the PSP, in most though something like link return or branch return). It is still quite possible to do such a thing, and if it is going to be potentially simple* as what I will note shortly then you might even be able to dodge much of that. Most hackers however then use a simple jump rather than something the processor/normal code might want to return from.
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.
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.
Everything before lowercase "a" is the player character's name, and everything after "f" is supposed to be a continuation of the alphabet, but somehow the text in memory is being changed after the first line. I'm glad to have a crumb of a working concept, but I need to play around with it more to see what's going on with the second line.
-
-
@
Julie_Pilgrim:
@Psionic Roshambo i have 16 gb in my pc and i run into issues with ram more than i'd like to admit -
-
-
-
-
-
@
Sonic Angel Knight:
Or, I also heard that if you use flash memory, it can act as more "RAM" at least windows tell me when I stick a flash drive into it. -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
K3Nv2:
I can think of the design teams process another joystick and no audio or a joystick and mono audio -
-
