The following warnings occurred:
Warning [2] count(): Parameter must be an array or an object that implements Countable - Line: 895 - File: showthread.php PHP 7.3.33 (Linux)
File Line Function
/showthread.php 895 errorHandler->error




Users browsing this thread: 1 Guest(s)
Sprite Loading format

#1
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
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.


The only true wisdom is knowing you know nothing.
  Find
Quote  



Messages In This Thread
Sprite Loading format - by Catone - 12-21-2015, 10:27 AM
RE: Sprite Loading format - by Everything - 12-21-2015, 12:18 PM
RE: Sprite Loading format - by Catone - 12-21-2015, 02:01 PM

Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite