Actually, the game supports ASCII and seems to be uncompressed so far. I might still look for the font file and all that if it's needed.
Time to translate Riglord Saga 2! WIP
- Thread starter DragonsOfSaturn
- Start date
Hi.
I analyzed part of this RPG code, here are some information that may be useful to you.
The font file is RIG2INIT.DAT.
Well, the text is apparently in vdp1, I don't know if at some point it can write text in the other vdp or with different routines (probably not, but who knows).
The text header of this game is encoded, but not exactly, I mean there is no table with text offsets that we can read in the hex editor (at least I didn't find one), but there is a table with variables that a basic decoding routine uses to pull the offsets of the texts, very simple.
From what I saw the game uses 1 word per letter, which is bad, and the way the font was made, it apparently wouldn't be possible to reduce it to 1 byte per character without major changes in the text writing routine, unless the game has some font with smaller pointers.
The way the "text writing routine" works is strange, but the concept is simple:
- The words in the text offset go through a calculation routine that results in pointers to the LWRAM, where the font archive is.
- The routine saves the character offset in the Stack and here's the trick: each variable (also in word format) that represents the letter/tile/pixels within the file goes through an routine that writes some values in a table, e.g. the first variable of the first part of character 7 is 3F80 (each character in this game is made up of 8 lines of code in vdp1), this 3F80 will be compared with the variables of the routine, and for integer results, some bytes are added in positions (virtual coordinates) of this table .
Finally, the table with the "character bytes" is pasted as it is in vdp1, forming the complete character.
Well, the font file has a large amount of space. Assuming the font file will not be unloaded from its offset, it is possible to replace all the Japanese characters with new text headers, this would solve the space issue.
I analyzed part of this RPG code, here are some information that may be useful to you.
The font file is RIG2INIT.DAT.
Well, the text is apparently in vdp1, I don't know if at some point it can write text in the other vdp or with different routines (probably not, but who knows).
The text header of this game is encoded, but not exactly, I mean there is no table with text offsets that we can read in the hex editor (at least I didn't find one), but there is a table with variables that a basic decoding routine uses to pull the offsets of the texts, very simple.
From what I saw the game uses 1 word per letter, which is bad, and the way the font was made, it apparently wouldn't be possible to reduce it to 1 byte per character without major changes in the text writing routine, unless the game has some font with smaller pointers.
The way the "text writing routine" works is strange, but the concept is simple:
- The words in the text offset go through a calculation routine that results in pointers to the LWRAM, where the font archive is.
- The routine saves the character offset in the Stack and here's the trick: each variable (also in word format) that represents the letter/tile/pixels within the file goes through an routine that writes some values in a table, e.g. the first variable of the first part of character 7 is 3F80 (each character in this game is made up of 8 lines of code in vdp1), this 3F80 will be compared with the variables of the routine, and for integer results, some bytes are added in positions (virtual coordinates) of this table .
Finally, the table with the "character bytes" is pasted as it is in vdp1, forming the complete character.
Well, the font file has a large amount of space. Assuming the font file will not be unloaded from its offset, it is possible to replace all the Japanese characters with new text headers, this would solve the space issue.
Attachments
Similar threads
