theopponent / st3-translation-notes Goto Github PK

There are no obvious locations where graphics containing text assets for these areas can be found, and it is likely they are compressed.

• Identify the source and format of scrolling VMU messages.
  • Kinematron messages are delivered on the VMU screen. Because not all memory units included a screen, there may be a method to bypass the screen delivery and show them on the TV screen if the game detects that the current VMU does not have one. If this is the case, or if modifying the VMU text proves infeasible, investigate forcing this detection to fail to recognize a screen.
    • We expect many players to use an emulator. The most popular emulator is Flycast, and while it does have an option to show the emulated VMU display on screen at all times, it is not enabled by default, and it is rendered over the game screen, which may be a distraction as it displays a static image for most of the game.
  • During battle stages, special attack names are scrolled on the VMU screen during the cutscene. Japanese attack names will need to be translated.
• Locate downloadable VMU binaries and identify text formats within.
• Modify static graphics such as the Sakura Taisen 3 logo.

The text engine properly centers LIPS text even after changing horizontal text offset, but it forces strange line breaking behavior on strings longer than 18 characters. This occurs after text is loaded to memory but before it is drawn to screen. In Double LIPS dialogs, when the choices change over after half of the time limit elapses, the text can be seen to be drawn correctly until the text animation ends, at which point the line breaking occurs and disrupts the strings. The limit of 18 characters will need to be changed or disabled for correct LIPS choice display.

Text in the option menu is placed in predetermined locations on the screen. In RAM, these properties are stored as part of an ASCII string in the format !i!h=75!v=95!x=206!y=158, with the Shift-JIS text immediately following it, then !d!o and one or two 00 bytes.

The function at 8c4c0154 is called when a character is drawn, and called in rapid succession when the A button is pressed to show all text instantly.

It is known that the number of entries in the 16-byte tables of the SBX files matches the number of function calls at the end of the text area, but it is not known how the bytes in each entry relate to those calls.

The known regions of the SBX format and the LIP files do not contain information on how the scripts are loaded and interleaved to form the order of the in-game dialogue. Text for voiced lines in the SBX files is not used by the game, instead being replaced by data in the LIP file. The correct order of this script is needed to determine the actual used lines in the SBX files and which lines are replaced by lines in the LIP files.

• Find the region in memory where the compiled script resides, if any.
• Find pointers to this region and how conditional branches (values changed by LIPS decisions, etc.) are executed.
  • Address 8c4c0154 contains a counter for the script location.
• Determine where graphics commands that change the current pose and text box portrait are stored and how they're executed. This information can be used to determine the speaking character for each line.
• Optional: Determine if the SBX files contain information on changing trust values depending on results of LIPS input.

Using a more familiar library may facilitate the palette conversion process, requiring less preparation from the user.

Keyboard controls should include the arrow keys and the Page Up and Page Down keys.

In the team status screen accessible during the intermissions, name labels for each character are drawn in predetermined locations within each badge. Changing these locations will allow for longer labels that are more natural for English text.

The texture for name labels is located in ADVDATA/EYECATCH/TAIN_DTS.CBD in PRS-compressed BPV1 form. The file ADVDATA/EYECATCH/EYECATCH.BIN contains strings and other data for the intermission screen.

The default text writing speed is one character every 3 frames. Because of the larger volume of text in a translation, this speed should ideally be increased. System messages as seen in the One Long Day mode have a faster writing speed.

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.

• 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.
• 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.
• 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.
• 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.