You have two problems to solve, assuming the game has no inherent support for half width characters.
1- Make the game read 1 byte and display 1 character, instead of read 2 bytes and display 1 character.
Often, this is handled by changing the read operation to only account for 1 byte, add an instruction to overwrite the "ghost" second byte with what the original programming is expecting, and send that to the original programming.
For example you'd redraw the font so that the characters in Shift-JIS area 0x8520-0x857F have the English ASCII set glyph graphics from 0x20-0x7F ... then, the game reads 2 bytes as usual, you're interested in the first so you tamper with the read (only keep first byte, then add 85) and then pass it over to the original code.
However... Some control codes would be something like FFFF or FEFF or whatever, and would be broken by this solution. You'll need to account for them. Either make it so that your hotfix mentioned above only happens when a "text mode" is on (through another control code perhaps?) or change the code after the hotfix to assign your control codes to single byte values. (I think the Summon Night Hajimari no Ishi project is struggling on this particular issue)End result:
Your text can be 2 times shorter.
It might still not be enough (look into adding a simple DTE/dictionary compression, while you're modifying the relevant programming?)
It will still appear double width and you'd run out of screen estate.
2- Make the individual letters appear half width.
Some PC-98 translators recommended making diffs of memory states between each frame of text displaying, to find the relevant addresses for the individual character positions and the advance value.
Some PS1 romhackers recommend a graphical debugger that gives the coordinate of each individual texture and instructions drawing it. I'm not sure an equivalent tool exists for PS2 or GameCube.
That's one of the higher barriers in such modifications. Maybe the Tear Ring Saga / Berwirk Saga translators have some expertise in that? They did do that, and then add variable width on top (changing that static value add, to a read from a table depending on the character then add that)
Looking at your screenshots, I noticed something peculiar with your half width experiment.
If you wrote "test" in ASCII for the first one, then considering JP-EUC has compatibility with ASCII (behaves exactly the same until 0x7F, then uses 2 bytes for other characters), it might be that the game actually does have the two options mentioned working correctly in fact, but there's a problem with the display, either:
- the individual character texture is stretched incorrectly
- the font data is pulled from garbage data instead of valid graphical memory
I think the width at the very least is correct. You might want to look into fixing the programming (font start offset) or texture (encoding it with a different width value?), considering you did your homework for the pointers?