Off-centre attack names

How a battle name is placed

The dialog font is proportional. The width routine FUN_80035F04 in SCUS_942.54 adds up one advance per character: the character's entry in the 256-byte width table at 0x80073F1C plus one pixel (dialog font). A correctly placed name then gets its left edge from three instructions: halve the width, load 0xA0 (160), subtract.

Two draw paths carry attack names. Summon cast modules call the text-label routine FUN_8003541C directly, passing the pen X as its fourth argument. Arts, items and monster moves write the X into four fields of the HUD placement table at 0x80076C10 (+0x722, +0x72A, +0x73A, +0x742) and raise the banner through FUN_801D8DE8 in the battle overlay, PROT entry 0898.

The width model used for every number on this page reproduces a position the project's notes record from an earlier capture: "Poisonous Sting" sums to 86 pixels, giving X = 117. It also reproduces the X of all seventeen summon captions logged at FUN_8003541C.

The Japanese build

The Japanese build (SCPS_100.59) has no width routine at all. A name is stored as a length byte followed by that many two-byte characters, and every character occupies a 12-pixel cell. Centring is arithmetic on the length byte: X = C - 6 × length, with C = 0xA0 (160) for a screen-centred name. Where the US code measures a string and halves the width, the Japanese code loads the first byte of the string and multiplies by six. The Lippian cast module calls the width routine twice on the US disc and has no counterpart call on the Japanese one.

The formula is exact only for full-width characters. The Japanese draw routine narrows a few, and that is what moves a hand-placed name a pixel or two off its nominal centre:

The Japanese caption register at 0x80032D10 is the counterpart of FUN_8003541C: it sets the 12-pixel cell and stores the pen X in the same node field. The Japanese overlays load higher than the US ones - the battle overlay at 0x801D05C8, the cast modules at 0x801F9DB0 - and the build is a separate compile, so its routines are found by content, not by address. The French build (SCES_019.44) is the US code relocated: every routine on this page matches it instruction for instruction, constants included, so the PAL release carries each defect described here.

What was captured

A breakpoint at FUN_8003541C on the US disc logged the string, the pen X and the Y of seventeen caption draws across eight summon casts. Every measured X equals 160 (or that module's own centre constant) minus half the width of the logged string, and every fixed X equals its typed-in number.

These were injected casts, not played ones: at the start of a party member's action the queued action was rewritten to the summon's spell, after which the game loaded and ran the cast module itself. HP values were poked to keep the fight alive, and some casts ran in a fight started from a forced formation. One row - Nighto's rarer outcome - is captured on a poked state: the outcome word was overwritten with zero to take that branch. What is logged is the pen position handed to the text routine, not a screenshot. The arts, item and "Points returned" banners go through the HUD table and were not captured.

"Ultimate Rave" is drawn off-centre

Reported as

After a Lippian Flute fails to kill, the attack name changes from a centred "Ultimate Death" to an "Ultimate Rave" that sits too far left (community report).

Cause

The caption's X is the literal 100, right for the ten-character Japanese name it was typed in for; the 78 px English string drawn there sits 21 px left.

Where

Lippian flute cast module, PROT entry 0924, load base 0x801F69D8; the literal at 0x801F7508

Affects

The failed (127 in 128) outcome of the Lippian Flute, on the US and PAL releases

Status

Explained - read from the code of the US, Japanese and French builds; the US pen positions logged in a running game (injected cast)

The Lippian Flute summons Lippian, whose attack tries an instant kill with a 1-in-128 chance. While the attack plays the caption reads Ultimate Death. If the kill does not land, the game swaps the caption for Ultimate Rave.

The two captions are drawn by two different pieces of code in the same cast module. The first one measures its text and subtracts half the width from the screen centre, like almost every other name in battle. The second one never measures anything: its left edge is the number 100, written directly into the instruction that draws it.

"Ultimate Rave" is 78 pixels wide in the game's proportional font, so it runs from 100 to 178 and its middle sits at 139 instead of 160. Measured and centred it would start at 121: the caption is 21 pixels too far left on a 320-pixel screen.

The number is the Japanese one. The Japanese cast module carries the same instruction with the same 100, in front of a name of ten characters: 160 - 6 × 10 = 100. One of the ten is a narrow middle dot, so that name is 116 pixels wide, covers 100..216 and sits two pixels left of centre. The English string was written over it and the number was kept.

As shipped

Where a measured caption would sit

Both captions are logged from a running cast (an injected one, see what was captured): Ultimate Death is drawn at X = 119 and, after the failed kill, Ultimate Rave at X = 100, Y = 150. The community screenshot that prompted the trace agrees: its caption starts about 99 native pixels in and is about 78 wide.

Mechanism

1. The cast module rolls the kill once at the start: random number AND 0x7F, kill only on zero. 0x801F6B0C
2. First caption: the spell name from the spell table, measured, X = 0xA6 - width/2. 0x801F7020
3. Second caption: the summon creature's attack name ("Ultimate Death"), measured, X = 0xA0 - width/2 = 119. 0x801F70F4
4. Near the end the module tests the kill flag; if the kill landed no new caption is drawn. 0x801F74E8
5. Otherwise it destroys the old caption and loads the module's own head string with X = 0x64 as a literal. 0x801F7508
6. The text routine puts the pen exactly at that X, so the 78 px string covers 100..178. FUN_8003541C

801f70c0  jal   0x80035f04      ; measure the name
801f70d4  sra   v0,v0,1         ; half width
801f70dc  addiu a3,zero,0xa0    ; 160
801f70f4  jal   0x8003541c
801f70f8  subu  a3,a3,v0        ; X = 160 - width/2

801f74e0  lw    v0,0x7c4c(v0)   ; kill flag
801f74e8  bnez  v0,0x801f7544   ; kill landed: no new caption
801f74f0  jal   0x800319a8      ; remove the old caption
801f7504  addiu a2,a2,0x69d8    ; string at 0x801F69D8
801f7508  addiu a3,zero,0x64    ; X = 100
801f750c  addiu v0,zero,0x96    ; Y = 150
801f751c  jal   0x8003541c

Addresses

Verifying it

Break on 0x801F751C during a Lippian Flute cast (it only runs on the failed roll): a2 = 0x801F69D8, a3 = 0x64. Or log a2 / a3 at 0x8003541C for the whole cast: three hits with X = 126, 119 and 100, which is what the injected cast logged. Changing the halfword at 0x801F7508 from 0x0064 to 0x0079 before that phase runs centres the caption.

On the Japanese disc the equivalent check is a breakpoint on the register call after 0x801FA900; that build was read, not run.

Sibling captions with a fixed or shifted position

Reported as

Other summon and item captions look slightly off-centre too (follow-up to the same community report).

Cause

Three more captions keep an X typed in for their Japanese names instead of a measured one, and ten summon spell names are centred on 166 or 172 rather than 160.

Where

Cast modules PROT 0907 and 0927, the battle overlay PROT 0898, and the spell-name captions of ten summon modules

Affects

Hell's Music, Dark Eclipse, Points returned on the US and PAL releases; ten summon spell-name captions by 6 or 12 px in every release

Status

Explained - read from the code of the US, Japanese and French builds; the summon captions logged in a running game (injected casts, one on a poked state); "Points returned" not captured

Scanning every caption draw in the summon and enemy cast modules, and every write to the battle name banner, turns up the same shortcut in three more places: a position typed in as a number instead of measured.

Hell's Music (Nighto) is drawn at X = 106 on the commoner of its two outcomes, Dark Eclipse (Juggernaut) at X = 112, and the Points returned banner of the battle overlay at X = 124. Against the widths of the English strings those are 21 and 14 pixels too far left and 6 pixels too far right. The Hell's Music case was found in the code and then captured: X = 106, Y = 150.

The three summon cases share one trait with Ultimate Rave: they are the only cast modules whose file begins with the attack name as text, and that head string is exactly the one drawn at a fixed position.

The same numbers on the Japanese disc

All four numbers are in the Japanese build unchanged, and there they work. Japanese names are fixed-pitch, so a position typed in by hand stays right for as long as the name does: the four Japanese captions land 2 pixels left, 4 right, 4 right and exactly on centre. The English release replaced the names with shorter proportional text, taught most of the code to measure it, and left these four numbers alone.

The literals are not the output of one rule. The first and last equal 160 - 6 × length. The Hell's Music and Dark Eclipse literals are one cell less than that, which lands closer to the true centre than the plain formula would because the middle dot is narrow; that they were set by hand is an inference from those values. The tempting reading - four slots of 10, 9, 8 and 6 cells - fits only the first and last: the names are 10, 10, 9 and 6 characters long.

Hard-coded X

For Nighto the module stores rand() % 8 at 0x801F8534. A non-zero value draws the head string at X = 106, Y = 150; zero draws the creature record's name (also "Hell's Music" on the US disc) measured and centred, 20 pixels lower at Y = 170. Both draws are captured: (106, 150) with the head string and, with the outcome word forced to zero, (127, 170) with the record name. Nighto draws two captions per cast - the spell name and one "Hell's Music". The Japanese module has the same gate (0x801FAE30..0x801FAE3C), and its zero arm draws the record name at 0xA0 - 6N, Y = 0xAA.

Logged pen positions

The distinct captions among the draws logged at FUN_8003541C on the US disc (injected casts, see what was captured). "icon" is the leading icon escape of a name; "literal" marks a typed-in X.

Measured, but not centred on 160

A milder inconsistency sits next to them. Each summon first shows its spell name, and that caption is measured - but ten modules subtract the half-width from 166 or 172 instead of 160, so those captions sit 6 or 12 pixels right of centre while their sibling modules use 160. The same modules carry the same constants on the Japanese disc, so this one is not a localisation artefact. Why those modules differ is not established, so it is recorded as a measured inconsistency, not as a proven bug. The last two columns are the Japanese build: the call site, and where the constant puts a Japanese spell name.

The record-name caption of the Evil Seru Magic cast module (PROT 0966, 0x801F7E28, Japanese site 0x801FB30C) also uses 0xA6, as does PROT 0926, whose tail repeats the caption code of 0925. Spell names come from the spell table; the leading plate or winged icon is an icon escape whose advance (20 or 28 pixels) is part of the measured width.

On the Japanese disc the spell names (name pointers at 0x80077200 + id*0xC) are plain strings - two or three kanji and a bracketed name, 7 to 10 characters - with no icon: the element plates and winged icons in front of the English names were added by the localisation. Two brackets at 8 pixels each make such a name 12N - 8 pixels wide, so C - 6N draws it centred on C - 4 whatever its length: 156, 162 or 168 for the three constants.

That rules out the two natural explanations of the shifted constants. They are not an allowance for the English icons, which they predate. They are not a per-name correction either: PROT 0903 and PROT 0908 draw Japanese names of the same shape and the same eight-character length (spells 0x81 and 0x86) with 0xAC and 0xA0.

Not affected

Everything else that shows a name in battle - monster attacks, monster spells, items, regular and Hyper Arts, the summon's own attack name - measures the very string it draws and is centred to within a pixel.

Addresses

Verifying it

Log a2 (string), a3 (X) and the word at sp+0x10 (Y) at 0x8003541C across one cast of each summon; any X that is not 160 minus half the string width is on the lists here. Eight injected casts logged this way produced the table of pen positions above, with no X off the lists. For Nighto the common outcome logs X = 106 at Y = 150; the other (one cast in eight, reached in the capture by writing zero to 0x801F8534 at the load at 0x801F7964) logs X = 127 at Y = 170.

"Points returned" goes through the HUD placement table, not FUN_8003541C, and is not captured: read the halfwords at 0x80076C10 + 0x722 / +0x72A while the banner is up and expect 0x007C.

Open questions

• Why ten modules centre on 166 or 172. They do so on the Japanese disc as well, so it is not a localisation artefact; the intent is unknown.
• Which in-game event produces id 0xFE and the "Points returned" banner (taken from the existing battle-action notes, not traced here).

Super Art and Miracle finisher names

Reported as

Super Art and Miracle Art finisher names are only centred when the name is about 12 or 13 characters long (community report; root cause traced by ZetaPhoenix).

Cause

The English banner is centred for the fixed name "Vulture Blade" where the Japanese code centred each art's own name; finishers have no table row to re-centre them.

Where

FUN_8004AD80 and FUN_8004C650 in SCUS_942.54; the fixed pointer at 0x80076024. Japanese counterpart at 0x8004D2E4 in SCPS_100.59

Affects

All fifteen Super Arts, the Miracle finishers and two Hurricane Kick clips on the US and PAL releases; worst cases Love You (-12 px) and Neo Static Raising (+14 px). The Japanese release is not affected

Status

Explained - read from the code of the US, Japanese and French builds; the banner was not captured on an emulator

Regular and Hyper Art names are centred. Super Art names, and the last hit of a Miracle Art, all start at the same left edge no matter how long the name is - so a short name like Love You hangs left and a long one like Neo Static Raising hangs right.

When an art animation starts, the banner code first centres the banner for one fixed name, Vulture Blade, whichever art is playing. It then looks the art up in the executable's arts-name table and, if it finds a row, replaces both the text and the position with the right ones. Regular and Hyper Arts have rows. Super Art finishers and Miracle finishers do not, so they keep the name from their animation record together with Vulture Blade's position.

This is a regression introduced by the localisation, not a design that was merely left alone. The Japanese code at the same place reads the length byte of the art's own animation-record name and centres on that, so on the Japanese disc every finisher is centred. An English record name is plain text with no length byte to read, and the replacement code measures one fixed table name instead of the name being shown. The French build carries the US code, so the PAL release has the defect too.

"Vulture Blade" is 13 characters and 75 pixels wide, which puts every finisher at X = 123. That is the "12 or 13 characters" of the community rule; because the font is proportional the exact condition is a width of 74 or 75 pixels, which Super Javelin and Dragon Fangs happen to hit.

As shipped

Each name centred on its own width

The root cause was traced by ZetaPhoenix, whose fix re-measures the installed name just before the banner is raised; this project ships that fix with his Super Arts Pack. The page adds the per-name numbers.

This and the Ultimate Rave caption are different routines on different draw paths, but the same class of mistake: the position is derived from a string other than the one that gets drawn, a few instructions away from code that does it correctly.

Mechanism

1. An art with action constant 0x1B or above is staged; the animation commit enters its banner block. 0x8004BB5C
2. It measures the fixed pointer at 0x80076024 - always "Vulture Blade", 75 px. 0x8004BBB8
3. It writes X = 160 - 37 = 123 into the four banner X fields. 0x8004BBD8
4. It points the banner at the name inside the art's own animation record. 0x8004BC10
5. It calls the arts-name lookup with (character, constant - 0x1B). 0x8004BC34
6. A matching row re-measures and rewrites X and the text; no row means nothing is written. FUN_8004C650
7. The banner is raised with whatever is in the fields: for a finisher, its record name at X = 123. 0x8004BC3C

8004bbb8  lw    a0,0x6024(v0)   ; *(0x80076024) = "Vulture Blade"
8004bbbc  jal   0x80035f04      ; measure: 75
8004bbcc  sra   v0,v0,1         ; 37
8004bbd0  li    v1,0xa0
8004bbd4  subu  v1,v1,v0        ; 123
8004bbd8  sh    v1,0x742(a0)    ; four X fields of 0x80076C10
8004bbe4  sh    v1,0x722(a0)
8004bc0c  addiu v0,v0,-0xcf0    ; art record name
8004bc10  sw    v0,0x74c(a0)
8004bc34  jal   0x8004c650      ; table lookup (character, id - 0x1B)
8004bc40  jal   0x801d8de8      ; raise the banner

8004d350  lbu   v1,0x1da(s2)    ; action constant
8004d370  lbu   v1,-0xcf0(v0)   ; first byte of THIS art record's name = its length N
8004d384  addiu v1,zero,0xa0
8004d388  subu  v1,v1,v0        ; X = 160 - 6N  (v0 = N * 6)
8004d390  sh    v1,...          ; the four banner X fields, to 0x8004D3A8
8004d3fc  jal   0x8004de40      ; arts-name lookup (character, id - 0x1B)

Every affected name

The fix shipped with the Super Arts Pack is described under randomizer internals. It repairs this banner only; the fixed-position captions above are separate code. Since each of those strings is constant, the equivalent repair would be one changed number per site.

Addresses

Verifying it

With a finisher banner on screen read the halfwords at 0x80077332, 0x8007733A, 0x8007734A and 0x80077352: 0x007B (123) for every Super Art or Miracle finisher, a name-dependent value for a regular art. Or break at 0x8004BBBC: a0 is 0x80013DAC whichever art is being installed. The banner goes through the HUD placement table and has not been captured; these positions are read from the code and the width table.

Open questions

• Why the pre-measure uses arts-name row 17 specifically; the binary does not say whether it was a placeholder or a default. The Japanese build has no fixed row at all.
• Whether Noa's row-less 0x1D / 0x1E clips are ever visible as separate captions during Hurricane Kick.