Condensing Spell List in Battle

... D'oh. XD Yeah, okay, total brainfart on my part, I have no idea how I missed that especially after you /pointed it out/. Yay, two more bytes saved? :D

Anything else like that I've missed that you can see?

Code:

     BEQ .noMoreSpells    ; so jump out, reset $F0 to start our lores

...

.noMoreSpells
TYX            ; reset our write-space index for the first Lore slot
BRA .checkLoreLoop

now that you got rid of the LDX at the later label, you can chuck that detour and change the BEQ to a new label between the early "LDY #$04" and "TYX".  saves 3 bytes.  due to my reordering suggestion, the "REP #$10" will have a superfluous execution, but no slower than the current BRA.

So, I'm going to be a tad bit presumptuous and assume that this will slide right into BNW and appear in the next major release (which is currently in beta - good timing with this). Who all should be credited here? Looks like Seibaby and Assassin have both contributed.

Also, I need an official name for this hack to refer to it by. I'll be calling it "Compact Spell List" unless otherwise directed.

seibaby and assassin should both be credited, yeah -- I don't /think/ seibaby contributed any actual code but I would be the LAST person to trust my memory on that, and anyway even without that I wouldn't have managed this without talking it through with him. And obviously assassin was instrumental in a) identifying a few initial key problems and b) getting it down to a much smaller size.

I've been calling it "Condensed Spell List" and the latest version in this thread is v1.3. I'll be uploading a proper .ips and the correctly commented assembly in the morning, because a lot of the comments haven't been updated since version 1.0. Oops? XD

Looks like your patch make the Alphabetical Rage patch and Muddle/Palidor fix obsolete (these 2 conflicts with your patch). The Muddle/Palidor fix got replaced by the SmokeBomb/Muddle Fix that was released recently (which doesn't conflict with your patch, yay!). Good stuff!

I'm not really familiar with the Alphabetical Rage patch - it may just be a matter of what free space this is writing to? I'm not at home tonight and I'm unlikely to have much time over the next few days (in fact, I had much less time TODAY than I expected, which is why 1.3 isn't uploaded anywhere yet) due to a convention I'm volunteering at this weekend, but I'll try to remember to take a look at it at the start of the week so I can see if I can get this compatible.

I'm glad it's not in conflict with the Muddle fixes, though! :D

I contributed no code at all to this, I was just sort of vaguely present to see it come to fruition. I don't think I've earned a credit just for assisting the author. That's what we do here!

Warrax, GrayShadows: yep, i'm pretty sure those are just incidental free space conflicts.  easily remedied, up until the time where free space is entirely run out of, but hopefully that's just shortly before the Sun becomes a red giant, and we all die.  if there's more than a 5-year gap between the two, is the intervening life really one worth living?

now, a conflict that is inherent is with my "Control attacks ignore MP cost fix", as they both edit C2/4F08.  ideally, GrayShadows goes all 1337sk37ch34, and releases an alternate version to coexist.  but that's not necessarily a responsibility, and it's somewhat early in this patch's development to worry about interoperability or free space location.

---

some space-related ideas:

1)

Code:

   BRA .weCopiedALore
   .checkNextLore
   INX #4
   .weCopiedALore
   TXY                ; and then copy it over to Y for our next loop through
   CPY #$00D8        ; if this is the last spell slot
   BEQ .checkNextLore    ;loop back up and INX again so we skip over it and point at our first Lore slot
   CPY #$0138
   BEQ .noMoreLores
   BRA .checkLoreLoop

i realized 2-3 days ago that if you just moved a spell from array[endList], the algorithm should really exit.  that is, there should be a check for pre-TXY Y here too.  now, you're able to do without, because either:
a) we just moved TO array[endList-1], so the post-TXY bounds check takes care of things right away.
OR, MORE SLOWLY:
b) after repeating the main loop from the top, your .findNextLore stretch of code will exhaust due to there being no more non-null entries left, so its bounds check will exit for us.

the current way can waste some cycles, but adding the check would take up space, and make the code a little more complicated.

however, thinking about it got me to wondering: is the following even needed?

Code:

   CPY #$00D8        ; if this is the last spell slot
   BEQ .checkNextLore    ;loop back up and INX again so we skip over it and point at our first Lore slot

i believe in their absence, the situation will either:
- be resolved by (b) above (and more quickly than a case where we moved an entry from array[endList] to somewhere early in the list).
- involve us finishing the original list on non-null entries, so the check at the top of the main loop (.checkLoreLoop) will fail, branching to .checkNextLore at the end of the loop -- bringing both X and Y to the start of the Lore list (or exiting, if we were processing lores).

so i'm thinking those two instructions, while logical, aren't truly necessary..  and that a speed argument in their favor is sketchy, given the longer potential wait already caused by the lack of a check for original (i.e. pre-TXY) Y.  meaning it comes down to whether removing them makes the algorithm less coherent, or whether i'm wrong about it being safe to do so.

--------

2) do you eventually plan to parcel part(s) of "calculateMPDeduction" back into the vacated C2/4F08, and call it/them with JSR(s), to save space?  i realize execution time is a concern, as this is already going to be FAR slower than the vanilla game's simple use of $3084, but several cycles for JSR/RTS might be outweighed by the space savings.

I'm not really familiar with the Alphabetical Rage patch - it may just be a matter of what free space this is writing to?

Yeah it's only a matter of free space. I wasn't very clear in my previous post (sorry English isn't my primary language), I just wanted to say that your patch made that one unnecessary (to me, at least) since it does the same thing (and more!).

??  his patch doesn't touch the Rage menu.  besides, Square already has the in-battle Rage listing condensed.