[JP->EN Translation] Converting 2-byte full-width kana into half-width romaji

[zeroshiki-project]

Hello all, and apologies if this is a common query in any way. I'm currently translating Onmyou Taisenki: Zeroshiki for the GBA from Japanese into English, and I'm wondering whether someone could give me advice as to how I can insert half-width romaji into the game, like what was done in the official translation of Pokemon Ruby. Zeroshiki uses Shift-JIS encoding, and I've taken screen captures of the unmodified intro screen, the text edited with half-width romaji and the text edited with full-width romaji. Since the text just doesn't appear, does it mean that all I need to do is find the graphic being addressed and create a font for it? Many thanks in advance for your help

https://imgur.com/a/48mfvJh

[FAST6191]

Most people around here probably would not frame it like that but it is a technically valid phrasing (many a game dev would have done that over the years when localising a game).

Sounds more like you want to alter the font width (and possibly line length and memory handling if the game needs it, if memory is not an issue and the game script indicates where new lines are to be then OK), and possibly drop down to an 8 bit encoding but I will leave that for now (not like the GBA particularly needs the space).

Equally games might appear to use Shift-JIS encoding but especially on stuff as old as the GBA that more often means they used a subset of it, or borrowed a selection of the encoding rather than make their own (not like Japanese has an order after all so not having to make one up solves an issue).
What the game's text handling is doing when you put what would technically be invalid characters in there is anybody's guess (or anybody that followed it through its assembly to see what it is doing) -- sometimes games will grab random (or mathematically what it would otherwise have been) tiles, sometimes it will have an invalid so print blank option, and other times it will crash a game.

Sometimes GBA fonts are nice and fully defined in their own little format (nowhere near as often as we would see it on the DS) but other times they are little more than tiles like any other that the game's own code will handle, and thus where you get to play. You might get lucky and the basic "add 16 unless number is greater than" thing is fairly easy to tweak to 12 or 8 and you then get to edit tiles accordingly.
There is a document covering a variable width font (and what is variable width if not a slightly more advanced skinny font?) addition to a GBA game -- https://www.romhacking.net/documents/337/ and it is not really that much different on any console other than the oldest of the old so have a SNES one as well https://www.romhacking.net/documents/245/


From a debugging approach.
Game text is 95% of the time in the background/BG layers. You can check this easily enough with sprite viewer and BG viewer options of your chosen emulator -- whatever the final output ends up in is what you care about for this.
To this end you are looking at the BG handlers rather than the OAM for sprites/objects/objs.
http://problemkaputt.de/gbatek.htm#lcdiobgcontrol
Even it the text appears all at once* in a given game the game will still have to go character by character fetching the relevant pictorial representation from its list and stashing it on a given location on the screen. Usually a simple +16 at a time (or +12 or +8), and this is where the variable width hack would add its own lookup to get the relevant width for the character and also make sure it did not go outside the horizontal boundaries** (and for the super rare descenders and ascenders (think yjgpq) hack then vertical as well). For a fixed width game (which is most Japanese things, especially of this era even if this was the start of things changing) then the game might have a counter to count how many characters it has displayed rather than use screen coordinates but no big deal and it will be obvious when you see it.
If you can't easily find the BG handler doing what it does you might have to find the script in the game first, and then follow it as it gets read and the pictorial representation of the text is generated.

*if it does appear like it is being typed out in front of you then you might even be able to do a nice text speed increase hack. Indeed other than a token tickling of whatever settings it might have and me seeing if I can crank it up to 11 (if the low-med-high options correspond to a nice variable that is less than the max I will see what going higher does) I would expect I end up looking at this sort of BG handler to see where the delay is and what I might do about it.

**technically many games will not worry here and have the script (new line values or maybe line/section length values) or pointers (if it is a line by line pointer setup that works here) be what serves to make sure all the text is contained where it is supposed to be. The GBA is just about new enough though that they reached the height of 1970s computing and had line wrapping in at least some games.