Patch: Pugs Rage

thanks.

i think (and hope) so.  yeah, my example should just be a hypothetical input.  for some reason, i was half uncomfortable "downgrading" your function to no longer be robust to even that. :/  but since you're comfortable with it, and the patch's random selection does not account for such a situation, might as well make the optimizations.

good theory on the reason for the strange loop, and the C2/05F2 change is sensible and elucidating.  i'd pretty much attributed vanilla's way to a sanity check with "emergency ejection", but that seems a bit abortive and panicky.  your way, complete with the branch tweak, is more logical and useful.  it's plausible that Square would miss code branching too far, if they changed the list format before that code ever activated.

With this in mind, I do not take the rage loop itself as any evidence that it is possible to have a compressed rage list with nulls in the middle.

good.  i saw no corroborating evidence, either, but would have been antsy about dropping it, "just in case".

re C2/A691:

1. thanks.

2. i was about to include the "SEP #$10" after initially glossing over it to focus on parts i was editing.  but then, i was thinking that the new function is agnostic to Index Register size:
a) it doesn't directly use X with immediates (e.g. "CPX #$00").
b) vanilla already does "C1/8531: BD 7E 25    LDA $257E,X   <= X holds the rage ID" without specifying/switching register size right before.

however, i forgot about the C1/662D path!  so yeah, it's safer to keep the "SEP #$10".  now, upon further examination yet, i think we might be able to:
a) insert "TDC" right before "LDA ($4F)", as C1/63FE will be zeroing the top half of A imminently, anyway.
b) accommodate (a) by changing C1/6635 to a BRA.

but it might not be worth it just to save 2 bytes, as your SEP is very straightforward and reliable (i.e. no code following needed to know X/Y size).

on (b)'s subject of optimizing vanilla callers (of C2/A691): is C1/853A indeed a pointless instruction?  if so, any way to harvest the 3-byte savings that'd result?  (none comes to mind, as C2/A691 needs to be fully callable by C1/662D as well.)

----

We only get 3 bytes out of C2/A691, but then C2/A6AB can be eliminated entirely.
In total, it is going to save about 24 bytes. 

If all checks out, I'll generate another set of patches to incorporate your optimization.

Thanks!

you're welcome.