Attempt to change offset for drawing text characters

[TheOpponent]

The message window forces line breaks after 16 characters, meaning that in practice, the script is expected to only use the manual line break (2F2F) for the 16th character in a line. Characters are 28x28, including spacing between characters. The current belief is that there is a hardcoded offset of 28 pixels that is used to draw each successive text character. If it is possible to change the size of these characters and allow for more characters to be drawn per line, any font can be used to replace the in-game font, and workarounds such as redefining the existing characters as two-letter pairs will not be necessary.

• [x] Allocate more memory for text.
  • The instruction at 8c0f24ca is d3 65 mov r13,r5, Changing it to 20 e5 mov #0x20,r5 to hardcode the character count from 16 to 32 causes that twice as much memory to be allocated for the text box, as well as the automatic line break to change accordingly.
• [x] Find the definition of the amount of characters in a line of text, 0x10.
  • The byte 8c10c658 is set to 0x10, and increasing it causes a corresponding increase in the region of memory allocated for text.
• [x] Find the definition of the horizontal text offset, 0x1C.
  • The instruction at 8c0f25c0 writes 0x1C to the ATXT region, but it is overwritten when the text box is initialized. The instruction at 8c0f2fd2 is 01 60 mov.w @r0,r0, which writes the value 0x1C for the text writing functions. Hardcoding this to 0e e0 mov #0xe,r0 does override the horizontal offset, not only to the text box, but everywhere else.
• [x] Find the definition of the text size, 0x1A.
  • 8c0f25b6 writes 0x1A to the ATXT region, and 8c0f2faa and 8c0f2fb4 write the value 0x1A for horizontal and vertical sizes respectively in the same manner as above.

Notes:

• The font is stored in the SKFONT.CG files. Each character is 13x13 in these files. Because of this, the value may be 13, 0xE, and multiplied by 2.
• Text characters are copied from the font resources into textures in memory on demand. Characters are not allocated from upcoming lines.

Update 4/17/2022: Control codes have been discovered that can change the text size and offset within the script, so hex edits to the binary will no longer be necessary.

[TheOpponent]

For dialogue scenes, properties for each text character are stored starting at 8c4bee00 or 8c4bee40. Information for each character is stored in 0xE bytes. There are bytes for size and horizontal offset, and each character can be adjusted individually, though the game never does this normally. Changing the offset will require finding the function that defines the text box character properties and changing the horizontal offset constant from 0x1C to 0xD.

https://github.com/TheOpponent/st3-translation-notes/wiki/Notable-memory-addresses#text-character-addresses

[TheOpponent]

Memory is allocated for 64 characters, and the engine forces line breaks after 16 characters. Although the offset can be changed for dialogue boxes, these limits will need to be overcome in order to make the most use of the text box.

[TheOpponent]

In disc 1, the instructions at 8c0f24c8 and 8c0f24ca normally write the values 0x4 and 0x10 respectively to a function that will allocate that many bytes to the region for containing four lines of 16 characters. The instruction at 8c0f24ca is d3 65 mov r13,r5, Changing it to 20 e5 mov #0x20,r5 to hardcode the character count from 16 to 32 causes that twice as much memory to be allocated for the text box, as well as the automatic line break to change accordingly.

The origin of the value 0x10 will need to be located to complete this hack.

[TheOpponent]

The byte 8c10c658 is set to 0x10, and increasing it causes a corresponding increase in the region of memory allocated for text. We have decided 30 characters per line will suffice for half-width text.

[TheOpponent]

The instruction at 8c0f25c0 writes 0x1C to the ATXT region, but it is overwritten when the text box is initialized. The instruction at 8c0f2fd2 is 01 60 mov.w @r0,r0, which writes the value 0x1C for the text writing functions. Hardcoding this to 0e e0 mov #0xe,r0 does override the horizontal offset, not only to the text box, but everywhere else.

For the text size, 8c0f25b6 writes 0x1A to the ATXT region, and 8c0f2faa and 8c0f2fb4 write the value 0x1A for horizontal and vertical sizes respectively in the same manner as above.

[TheOpponent]

Text locations and alignments will need to be adjusted for all locations where text is written. Patching the instruction to write a hardcoded value disrupts text alignments in the option menu.

[TheOpponent]

We have discovered control codes to dynamically change text properties within the script. These can be used in lieu of hex edits to the binary to allow for more text per line.

[TheOpponent]

A proper hack has been documented at https://github.com/TheOpponent/st3-translation-notes/wiki/1ST_READ.BIN#changing-dialogue-box-text-properties