Sprite Loading format

If someone has a better/more accurate title for this thread, by all means lets hear it. I'm drawing a blank.

I'm trying to figure out the difference between sprites #85 (dec) and below vs #86 and higher.

First noticed a difference in how FF3usME listed them, vs how LE listed them (sprites that is). usME does some formatting then list/displays them in a working visable format (as well as combining one and leaving a few value completely out of the list, leading to a numbering system that doesn't match exactly with the rom npc table or LE.

LE give a more raw list, including some "blank" spaces every other sprite that matches up to the NPC pointer table in the ROM. It also requires you to adjust the special bits/check boxes for any special formatting of such items (ever tried to place the 4-Ton weight Ultros uses? Or Umaro's skull totem?) Not only do you have to get the boxes checked right to properly display the sprite, but the direction facing as well. I don't know why it requires special setting, but doesn't matter to much for this, that's not the question.

THE question: Loading a normal sprite sheet into one of those numbers above #85 will load as a PC, on the map. In battle however, you'll get glitched unrecognizeable sprites. (#86-#90 tend to be distorted colors and "glitched", #104 is just a perfect white block, #154 gives you just a shadow and no sprite or glitch.) Where is the question? Right here -> WTF?

Its resonable that NPC sprites can load from those special sheets/special formats, by using flags in the NPC data, but what does that have to do with loading a standard format PC sprite sheet as a PC? The code for loading battle sprites was never intended to load from those special sheets so why would it have any special formatting to screw up loading a normal sheet from that value in the battle sprite's table?

The only thing that stands out to me as to where the problems start is that from #86 up has those values every other one that seem to have nothing in them. But I still fail to see how/what would stop the battle sprite code from loading that offset from the table and loading a standered sheet in a format it always uses.

And yes, for the record, all the basic things are set to handle loading those sheets, (offset tables, palette tables, entrance moves/actions, etc).
The same issues happen with or without Eggers' extended palette hack (returning all the original code with adjusted offsets for new tables resulted in the same issues, only change was that sprites below #86 only used the normal 12 colors obviously).
Other things like OAM data and such "should not" be the issue here, based on the fact the normal PC OAM list don't go above 22 or so, let alone #85. If that was the issue (unless there is another list somewhere else that went from #0-#85) I wouldn't only have the problem from #86 and up.

Its not a show stopper, it just pisses me off. Have ways to get around it and still come out ahead but... yeah to put it simply: WTF?

Suggestions/information welcome.

Thanks for reading.

I think I know what the problem is. In the character graphics loading subroutine at C1/3D43, it multiplies the graphics index by 3 to get a pointer to the sprite graphics pointers at C2/CE43. It does this with an 8-bit accumulator, so values greater than 85 will overflow (85 * 3 = 255). You could probably fix it with a little asm hack. The actual multiplication code starts at C1/3D56.

I do see the problem, course I manged to fix the main broke one, and break 6 others in the process. Does prove for a fact that it is a problem, if not THE problem. The table at C2 might also become an issue, but getting to it has to come first.

That solves the mystery, just a matter of coming up with the propper solution.

Thanks!

---

I can get some of it to work, but it looks to be holding some garbage over after the first character slot or three.

Since I'm using Eggers' Expanded Palettes this peticular code isn't where it normally should be but is mostly unchanged in that spot.
Starts at line #89 in his ASM file.

Code:

C1/3D56:
LDA $14
ASL A
CLC
ADC $14
TAX

LDA #$C2
STA $16
PHB
LDA #$7F
PLB
LDA>$410002,X
STA $12
REP #$20

That probably isn't much help but anyway, the problem is when it does the ADC $14 the created offset goes beyond 8-bit handling. I tried to put it in 16-bit for those calculations (just after the LDA $14) and it will crash with just that. Adding a SEP#$20 after the TAX then will keep it from crashing and keep the proper values in X for awhile, by the thrid or fourth character slot (repeating this line of code) it will load... junk at the ADC $14. Depending on how I arrange the character to load, sometimes it will have junk on the third pass (resulting in a bad offset and glitched sprite) and run clean on the fourth pass. Rearrange the same characters and it will produce a junk value on the fourth pass. All values/math seem to be correct until it gets to the ADC $14 (even on the passes that glitch).

I keep looking to see if it would be possible to move that calculation down below where it normally does the REP #$20 but every time I think of a way I find an obvious reason it won't work.

Not sure where the "junk" value is coming from, or why it isn't consistantly showing up on the same pass every time, and not sure how to get around it.

On a related subject: How do you tell a compiler to use a C9 instead of a C5 for a CMP?