We've been reading the trace logs and the disasm, it seems the key glitch is macro glitch. You spawn the broken char and he corrupts the macros, so then you try to use those macros and due to having more chars than possible (6?), the lookup overflows, reading arbitrary data (0x27) as "
battle object ID". It then tries to resolve it to some char data and overflows once again, ending up with 0x158 characters it thinks you have. And when setting them up, it finally does the "byte shift", which is not byte shift at all.
Language: asm
005694: 23B1 move.l (A1,D3.w,4), (A1,D3.w) ; swap next fighter with current
00569A: 5843 addq.w #4, D3 ; do the same for next pair
00569C: 51CA dbra D2, $5694 ; decrement D2 and jump back to 005694 unless D2 is $FFFF
Before that, the starting address (
Battle_Turn_Order) of the area to be corrupted is loaded:
Language: asm
00568A: 43F8 lea $FFFFEFB0.w, A1
And so, corruption loops up to address
$FFEFB0 + $55C + 4 = $FFF510. Then some more, but you get the idea. It's not a byte-wise shift. It copies over 4-byte chunks that 68K calls longs, and the offset is also 4 bytes.
Now, should we call the glitch and this branch "long shift"? I don't think it tells anything helpful to the viewer either. I prefer "macro glitch". This seems to be the most important "feature" of the broken char. Does anyone want it to be something else?
What happened in those rooms? I discarded all the loading screens where possible btw.
Actual text of the manual:
Game title screen:
Box cover:
.jpg)
It could be argued that both versions are fine.
Is this the "byte shift" glitch? I see memory corruption and then you save the game, reset, and continue. It looks like you're loading the corrupted save data and that's the main feature of the movie. Is that correct, or you might as well not save/load there and just keep playing, getting the same speedrun benefits?