Credits to @AlfredKamon for discovering this. From some testing that he and I have done in regards to expanding the number of classes you may have, it seems that there may be a “cap” on the maximum amount of standing map sprites. It seems you may only have up to 128 standing map sprites. In other words only indexes 0x00 through 0x7F are valid for standing map sprites. Using a standing map sprite with an index over this value will cause the map sprite to not load/it seems to load a broken version of which ever map sprite would come next if the array looped around. So using index 0x80 for a standing sprite causes a broken version of entry 0x00 to load instead.
Moving map sprites do not have this “cap.” This has only been tested in FE8, but I imagine this holds true in all FE games, possibly explaining why FE8 removed so many map sprites from FE7/why some classes share map sprites.
For reference, to my knowledge there are at least 165 standing map sprites publicly available in the community at the moment(this includes custom ones found in the FEU thread). For those of you planning to take advantage of Icecube’s class expansion patch, keep this in mind.
Does Icecube’s patch fix this issue too then?
I’m guessing it doesn’t. More like “If you use Icecube’s patch, you’ve got to keep this limit in mind.”
As Primefusion said, it doesn’t, hence this is just something to keep in mind while working on a hack with an expanded number of classes.
I am confirmed that someone has transcended the limitation without a great effort so maybe you can have a try?
I am having some trouble understanding exactly what you are trying to say so I will do my best to answer what I think you are asking.
There is currently no solution for this issue.
I lack the skills to solve it, so I’m just reporting it to warn people it currently exists.
if the issue is what i think it is it’s probably trivial to fix
Oh cool. If you/someone else come up with one I’ll be happy to test it out.
I just suggested you to have a try because I heared that it is not too difficult to solve from someone before. Eh, no other meanings.
I have not check all possibilities of it, but if the last bit isn’t used, we just need to change 7F into FF in these address.
Setting all those addresses from 7F to FF at least fixes the loading problem that occasionally popped up, but animations don’t play(so it only loads one of the three standing frames and sticks with that one frame). Also anything beyond entry 0xD0 seemed to load either the top part of the… next map sprite a unit on the same team had? The entries at 0xE0 or higher just loaded the whole map sprite of said team unit.
By all possibilities do you mean that some of those offsets may not have to be changed to 0xFF?
I did a survey just now and found the reason of the limitation:
As I guessed, there is an and operation to remove the highest bit here. Replace the operation “mov r1,7fh and r1,r0” with “mov r1,r0 nop”.
@Blademaster: Found the problem. Changing 26A52 to 2000 fix the animation problem (IMO, that’s the problem. The point is to make r1 = 1 to execute the animation).
@MisakaMikoto: What ROM is it? AFAIK, 25C48 is 00 28 1E D1 (FE8 US)
The rom I researched is FE7(J).
@Icecube I’ve edited all of those to FF and wrote 2000 at 26A52, but it still isn’t working.
I’m using the standing sprite 0x88, and it just loads a… shadow, I think?
Do you mind sending me a patch and the save file?
Sure. This may take some hours though, I’m not at home now.
I tested according to my discovery and found that even if I broke the limitation there was a glich like what @Blademaster said, and then I found that: the highest bit of index is not useless as you imagined. In fact, it determines whether the animation can play: 1-cannot, 0-can. I know it may sound absurd but you can do a simple test to find it out yourself. To conclude, the highest bit is a control bit, while the least 7 bits are index bits.
@Icecube Nevermind, it works now!
I’ve double checked it and it seems I had missed one of the offsets before, since I was in a hurry.
Huge thanks, icecube!
I confirm that this fixes the problem in FE8.
@AlfredKamon: Glad it works.
@MisakaMikoto: Are you sure that you’ve found all filters? I don’t know about FE7(J), but in FE7(US), I found that
should be changed into FF and
should be changed into 2000 (mov r0,0x00).
IMO it’s safe to edit it because the Standing Sprite ID has not been changed since the last read.