Users browsing this thread: 1 Guest(s)
Patch: Pugs Rage
your patch is currently robust to the following list:
00 01 02 02 03 04 05 05 05 06 07 07 08 08 08 [...]
in terms of menu handling. however, given that you ditched the strange loop C2/05ED - C2/05F9 and don't attempt to replicate its list crawling or sanity checking, i believe your patch is NOT robust to the above list in terms of random selection.
if that is acceptable/intended *and* you're willing to go further in that direction, i _think_ you could save ROM space by leaning harder on the $3A9A counter variable and the fact that the in-battle Rage list is compressed (i.e. blank-less). this should allow the following corner-cuttings / optimizations:
1) shrink Function C2/A691 by a few bytes, replacing the $257D,X check with a $3A9A check:
i'm not even sure that'll run as intended.
2) drop most of the C2/A6AB function by no longer padding the end of the list.
----
the thing is, i LIKE that your current patch method is robust, for menu handling, to the above example. so i'm not ACTUALLY advocating you change things in this way. rather, i'm interested in whether you think it'd work (both the idea and my code attempt), and if so, how many bytes could be squeezed out of the patch code. or conversely, whether you think it's worth adding "smart crawling" dupe-accounting to the random Rage selection. (not to say it's necessarily an either-or choice; neither could also suffice.)
admittedly, i first decided to make this post back when i thought i could reduce C2/A691 by ~8 bytes, before remembering to account for the ($3A9A == 0) edge case.
00 01 02 02 03 04 05 05 05 06 07 07 08 08 08 [...]
in terms of menu handling. however, given that you ditched the strange loop C2/05ED - C2/05F9 and don't attempt to replicate its list crawling or sanity checking, i believe your patch is NOT robust to the above list in terms of random selection.
if that is acceptable/intended *and* you're willing to go further in that direction, i _think_ you could save ROM space by leaning harder on the $3A9A counter variable and the fact that the in-battle Rage list is compressed (i.e. blank-less). this should allow the following corner-cuttings / optimizations:
1) shrink Function C2/A691 by a few bytes, replacing the $257D,X check with a $3A9A check:
Code:
phx
tax
pha
lda $3a9a
dec
cmp $01,s
pla
lda $257e,x
plx
rep #$12
bcs done
sep #$02
done:
rtl
2) drop most of the C2/A6AB function by no longer padding the end of the list.
----
the thing is, i LIKE that your current patch method is robust, for menu handling, to the above example. so i'm not ACTUALLY advocating you change things in this way. rather, i'm interested in whether you think it'd work (both the idea and my code attempt), and if so, how many bytes could be squeezed out of the patch code. or conversely, whether you think it's worth adding "smart crawling" dupe-accounting to the random Rage selection. (not to say it's necessarily an either-or choice; neither could also suffice.)
admittedly, i first decided to make this post back when i thought i could reduce C2/A691 by ~8 bytes, before remembering to account for the ($3A9A == 0) edge case.
« Next Oldest | Next Newest »
|
||||
Users browsing this thread: 1 Guest(s)