Skip to content

Fix the lbshadow bezier constant and lay out its .sdata2 pool - #2971

Draft
MarkMcCaskey wants to merge 3 commits into
doldecomp:masterfrom
MarkMcCaskey:match-lbshadow-sdata2-order
Draft

Fix the lbshadow bezier constant and lay out its .sdata2 pool#2971
MarkMcCaskey wants to merge 3 commits into
doldecomp:masterfrom
MarkMcCaskey:match-lbshadow-sdata2-order

Conversation

@MarkMcCaskey

Copy link
Copy Markdown
Collaborator

I'm going to keep grinding on this and see if I can get matches here.

From Claude:

The cubic bezier tangent wrote bez1 as (-4.0f * t) + 1.0f, but retail's .sdata2 holds +4.0f and contains no -4.0f at all, and the target emits fnmsubs where the negated form emits fmadds. Writing it as 1.0f - (4.0f * t) restores both, and drops the pool from eight constants to retail's seven.

MWCC orders the literal pool by first appearance in the source, so the recovered constant alone reshuffles it. Add the usual sdata2_order anchor - as itzako, grrcruise and friends already do - to pin the pool to retail's order. .sdata2 goes from 86.79% to 94.34%; the remainder is a second 0.0f and 1.0f that retail holds separately, which one translation unit cannot reproduce.

lbShadow_8000E9F0 keeps one two-instruction scheduling transposition (fnmsubs against the t2 multiply); every other function and .data are byte-identical to before.

The cubic bezier tangent wrote bez1 as (-4.0f * t) + 1.0f, but retail's
.sdata2 holds +4.0f and contains no -4.0f at all, and the target emits
fnmsubs where the negated form emits fmadds.  Writing it as
1.0f - (4.0f * t) restores both, and drops the pool from eight constants
to retail's seven.

MWCC orders the literal pool by first appearance in the source, so the
recovered constant alone reshuffles it.  Add the usual sdata2_order
anchor - as itzako, grrcruise and friends already do - to pin the pool
to retail's order.  .sdata2 goes from 86.79% to 94.34%; the remainder is
a second 0.0f and 1.0f that retail holds separately, which one
translation unit cannot reproduce.

lbShadow_8000E9F0 keeps one two-instruction scheduling transposition
(fnmsubs against the t2 multiply); every other function and .data are
byte-identical to before.
@decomp-dev

decomp-dev Bot commented Jul 25, 2026

Copy link
Copy Markdown

Report for GALE01 (1b5c160 - 84ea803)

📈 Matched data: 87.19% (+0.01%, +112 bytes)

✅ 2 new matches
Unit Item Bytes Before After
main/melee/lb/lb_E9F0 .sdata2 +40 0.00% 100.00%
main/melee/lb/lbshadow .sdata2 -25 86.79% 100.00%
📈 1 improvement in an unmatched item
Unit Item Bytes Before After
main/melee/lb/lb_E9F0 lbShadow_8000E9F0 +852 0.00% 98.16%
📉 1 regression in an unmatched item
Unit Item Bytes Before After
main/melee/lb/lbshadow lbShadow_8000E9F0 -863 99.42% 0.00%

The spline tangent evaluator at 8000E9F0 shares no .sdata2 constants with the rest of lbshadow, while every later function draws from one shared pool: lbShadow_8000F38C reuses 0.001f and 1.2f from earlier functions, and 0.0f/1.0f each appear twice, once on either side of the boundary. One translation unit cannot emit those duplicates, so the original build compiled the evaluator separately.

With the split, lbshadow's pool lays out in natural first-appearance order and drops the sdata2_order anchor entirely; lb_E9F0 keeps a private eight-constant anchor. Both .sdata2 sections are byte-identical to retail, lbshadow's other five functions are exact, and its .data/.sdata contents are unchanged. ground, grmutecity, and grbigblueroute compile byte-identically with the moved declaration.

lbShadow_8000E9F0 keeps its two-instruction scheduling transposition and lbShadow_8000F38C still differs by one recycled zero init.
@ribbanya ribbanya added the ai-assisted Utilizes a LLM to do the heavy lifting label Jul 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai-assisted Utilizes a LLM to do the heavy lifting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants