Users browsing this thread: 1 Guest(s)
Mass Sprite Sheet Expansion Battle & NPC

#11
Posts: 1,628
Threads: 56
Thanks Received: 47
Thanks Given: 127
Joined: Apr 2014
Reputation: 12
Status
Refresh
You misunderstood my question: i was asking you which actors IDs didn't had any problem with assigning them a spritesheet, in other words.
So... who were those slots... some dummied kefka, the misterious actor with Shadow gears, maduin, another one? That was what i meant.


THE GREATEST CHALLENGE OF ALL TIMES AWAITS:
http://www.ff6hacking.com/forums/showthr...p?tid=2593
DO YOU HAVE WHAT IT TAKES TO SLAY A GOD?
------------------------------------------------------------------------
Tenkarider's project #2 is started: FF6 Curse of the Madsiur Joke (CotMJ)
http://www.ff6hacking.com/forums/showthr...p?tid=2755
What happens when Madsiur tweaks your account? This full game hack will show that!
  Find
Quote  

#12
Posts: 579
Threads: 33
Thanks Received: 32
Thanks Given: 22
Joined: Jan 2015
Reputation: 9
Status
Dead
Didn't know there were issues with any actors of that sort. Those were just the default Moogle actors already loaded for that battle,(when Locke jumps in to save Terra from Narsh guards).

I used that event for testing because there are 11 pc assigned graphics, palettes, and properties all in one nice little place right after a multiple choice dialog. That being said, I didn't change anything in regards to what name/properties they were assigned.

Since you brought it up though (and it is definatly relevant to using something like this) I will be sure to go back and test all the available names/properties to see if they'll all function with graphics. Never thought of them being an issue before.

*UPDATE* Still no progress on making every graphics sheet work in battle. Some of them just refuse to load.

It's not the location of the sprite. I can tell it to load the graphics for Clyde, and change the battle pointer to the Draco sprite sheet and it will load Draco in battle correctly.

The problem is not in the NPC pointers. I've edited the expanded battle tables (sprite and palette) as well as another table from CF/F913 that is called at C3/6CF7 that I don't even remember what it is for... as well as the map character pointers at C0/D0F2 area, everything I can find pointed at the new full sprite sheets and it still won't load certain battle sprites. Debug says it is going to the proper location for the sheet, it just won't work. (Sometimes just a blank space, sometimes a shadow and no character, sometimes a blob of glitched pixels, sometimes complete crash on battle start.)

I attempted to look at the info at C2/C745 labled as "Pointers to Sprite Parts used in battle". Can't make any sense of the actual data, even after reading Egger's comments regarding that data during sprite loading. That being said, the debug log shows that the table is being read (as far as I can tell) the same manner with sprites that work and sprites that don't. If that is the problem, I'm not sure how to even narrow it down let alone fix it because it seems to be doing it correctly.

My best guess at this point is: math. Somewhere in the code it seems the sprite value for some just doesn't factor into the original formula for loading battle graphics while other values just get lucky, I'll be damned if I can see a pattern to it though. I SUCK at math though so if it is the problem, pure dumb luck, random guessing, or deals with the dark side are the only way I'll be able to make it work personally.

At this point in time I am planning to continue expanding sheets and making a list of what crashes in battle, which at the moment seem to be several more than I like to see including some I actually had plans for. The NPC sheets will still be expanded to full size, they just wont work in battle. So it won't be a complete waste, just not as good as I had hoped.


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

#13
Posts: 1,628
Threads: 56
Thanks Received: 47
Thanks Given: 127
Joined: Apr 2014
Reputation: 12
Status
Refresh
It was a brave goal since the beginning: even just 1 extra sprite would be a progress, right? (of course, it would be much more better if it will become a complete success)
Don't give up! Objection!

P.S. i really have serious problems in learning how to use debuggers, in general... Finger
the one of snes in particular!!! it's really something if you understand what comes out from it(from my point of view)


THE GREATEST CHALLENGE OF ALL TIMES AWAITS:
http://www.ff6hacking.com/forums/showthr...p?tid=2593
DO YOU HAVE WHAT IT TAKES TO SLAY A GOD?
------------------------------------------------------------------------
Tenkarider's project #2 is started: FF6 Curse of the Madsiur Joke (CotMJ)
http://www.ff6hacking.com/forums/showthr...p?tid=2755
What happens when Madsiur tweaks your account? This full game hack will show that!
  Find
Quote  

#14
Posts: 579
Threads: 33
Thanks Received: 32
Thanks Given: 22
Joined: Jan 2015
Reputation: 9
Status
Dead
I've still got an idea or two, and I still have to figure out why Egger's extended palettes won't work (for those npc that use impropper PC colors).

On the probability I can't get them all to work, I'm debating the idea of switching some npc around. Move some base npc that no normal person would want in battle that works, and swapping them with stuff like a Returner, or Draco, or such that doesnt work in the current place. This would at least allow more uncommon npc to be used, while also making less impact to swap out a less common npc for custom jobs. Its an option, worst case. Time consuming to swap all instances but not difficult and would still add to the end product.

Fixing it still has a higher priority atm though but, not many ideas left.

As for debuggers, hard to aim. As in to get them looking at what you want. Even with break points set. My case was fairly easy to read because my code was the only thing pointed beyond normal banks.


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

#15
Posts: 127
Threads: 8
Thanks Received: 41
Thanks Given: 29
Joined: Jan 2012
Reputation: 13
Status
None
Have you updated the "Pointers to character battle graphics" at C2/CE43?
  Find
Quote  

#16
Posts: 579
Threads: 33
Thanks Received: 32
Thanks Given: 22
Joined: Jan 2015
Reputation: 9
Status
Dead
So far I've:
  • Expanded the Battle Graphics Pointer Table at C2/CE43
  • Expanded the Battle Character Palettes at C2/CE2B
  • Expanded another list of pointers to character graphics at CF/F911

All three of those list now cover from sprite sheet 00-63 (Terra - Ramah in Decimal).
All three list have been moved and now start at 41/0000

I've changed the pointers to those list at:
  • C1/3D66
  • C1/3E20
  • C1/3E20
  • C3/6CF7

I didn't move the list at C0/D0F2 and the bank pointers at C0/D23C for Map Character Graphics because it didn't need to be expanded. I have changed those values on a sprite by sprite basis to point toward the graphics sheets I've put in at 41/0A00 and up to see if it helped... didn't help in battle (obviously) but it did load the proper full sprite sheets that I pointed them too, out of battle naturally.

As of now, I've had no success what so ever in loading the following graphics in battle:
  • 27 - Scholar
  • 28 - Draco
  • 30 - Returner
  • 58 - Fish

The following graphics load without error in battle:
  • 35 - Clyde
  • 40 - Bird
  • 41 - Rachel
  • 47 - Cid
  • 48 - Maduin
  • 55 - Esper Fairy
  • All of the normally usable battle sprites (Terra - Imp + Leo-Gesthal)

I've tried mostly everything from 23-34 (Numbers in Decimal btw) Graphics sheets assigned to a character and none of those worked either. I didn't mark them as officially broke because I didn't write down exactly which ones I tried when I did it. I've been using 30 (Returner) and 27 (Scholar) as test subjects while trying to get it to work. Sheet 30 just shows up with no sprite, sheet 27 glitches and tries to crash the game when you enter battle (Sometimes it crashes, sometimes it just glitches horribly). So far, no success on either of them.

I can however, change the pointer for Locke's sprite sheet in the expanded table, to the location where either the Returner or Scholar sheets are located and they will load and work, just not using their own numbers (as in assign graphics 1B to Character 01).

I would have thought using 41 as a bank pointer instead of FF or in this case 101, would have caused issues but other than those certain numbers, the rest work and load fine from the expanded-expanded Rom space. (as in over 4mb).

Using the extra expanded space, I also thought maybe the broken sprite pointers might be in a "dead zone" of memory that didn't want to read properly while the rest of the table was... however when I ran the debugger it showed that it was loading the proper location from the table while trying to load the sprite (the values added up, and there was no other way for it to get a location of 43/6CE0 unless from that table, with that offset.)

I've checked my table numbers to make sure I didn't make a typo or count them out incorrectly, however, if I was off by 500 or 600 bytes it would still load a glitched sprite or half a sprite. On the broke values, it is like it is pointed at nothing (on some of them), yet as I said, if I put the same value in a working value slot, it loads fine from the location it should be in (where I put the sprite sheet to start with).

Unless I've missed a pointer to the table somewhere that I absolutely can't find, it almost has to be something to do with assigning a value like $1B to X to use as an offset for the table. (I think I said that correctly). As in the standard formula just doesn't want to handle THAT value, but a value of $23 or $2F works fine? I don't see a pattern there, or anything that would have a problem with one that would work with the other. And again, the debugger showed the proper destination for the broke sprite sheet while loading it.

So if the code is using a value like $1B to read the expanded table properly, what would stop it from showing the sprite in battle after initial loading, but before the characters appear on screen?

Could it be an issue in the formula for reading palettes? Moreso reading the table with the higher sprite ID (or something to that nature.)

Yeah, its a very long post. Kinda hoped explaining it all fully would give me an idea of what to look at, but so far nothing.


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

#17
Posts: 127
Threads: 8
Thanks Received: 41
Thanks Given: 29
Joined: Jan 2012
Reputation: 13
Status
None
This might be a problem with the palettes. Try setting the same palette (one that works) to all character sprites and see if you get them to load.

Egger says in his ReadMe
Quote:In battle, however, character sprites "give away" a partition of their palette
to other, miscellaneous sprites, such as the hand cursor, damage digits, and
so on. PC sprites only use the first 12 colors, while the other sprites only
use the last 4. So, if you create a PC sprite that uses the last 4 colors,
those colors will show up as colors from the hand cursor or something else,
instead of how they're supposed to.

[...]


So, even with this patch, you are still limited to 12 colors, but they can be
any 12 of your choosing.

Seeing as Egger's patch detects your colors and creates a palette by itself I think you might need to be careful that the sprites do not contain more than 12 different colors.

Then I also noticed some variables that might worry in his code:
Code:
LAST_BASIC_SPRITE_OFFSET .EQU 22        ; 22 sprites are used as battle sprites in the original game. Gestahl
                                        ; is number 22.
NUMBER_EXTRA_SPRITES .EQU 32            ; In case someone adds new battle sprites, we'll handle this (in a very
                                        ; slightly less efficient way). 32 should be more than enough.

So battle sprites above Gestahl are handled differently by Egger. Therefore this might be an issue or conflict with Eggers patch. I would recommend doing the expansions first on a vanilla game and adding Eggers patch after if you need the dynamic palettes.
  Find
Quote  

#18
Posts: 579
Threads: 33
Thanks Received: 32
Thanks Given: 22
Joined: Jan 2015
Reputation: 9
Status
Dead
All of the "new" battle sprites I'm using currently all use a standard PC color palette setup. As I said, they load fine if I load them using a working sprite ID (35, 40, 41, etc). It doesn't matter which sprite sheet I tell it to load, just as long as I only load it using the IDs that work. So it shouldn't be the 12 color limit stopping them. I haven't paid any attention to how many different palettes are being loaded at one time though (didn't think to even look because they worked on different IDs) so maybe, big maybe, be just getting unlucky on that count but it shouldn't be a problem because they all use the basic palettes and normal PC colors at this time.

As for Egger's patch, it only accounting for 32 extra battle sprites could be a problem eventually, and while my table of pointers includes more characters than that, I'm not currently using more than that. I would need to use his patch to make those NPC that use colors outside of the normal 12 work without major changes (like Arvis, the dancers, Narsh guards). I had tried to instal it before I had those sprites imported to see if it would in advertanly fix the problem with some of them not loading (since he DID account for sprites beyond 22).

Every time I've tried installing it though I get crashes at every screen load as well as the title screen not loading either. I've tried using the IPS to patch it, I've tried using the asm file to make changes to pointers and adresses then instally it manually with the same result. Even if it wasn't compatible with my expanded list or extra sprites, it shouldnt be causing crashing of the game to that extent. So I'm still not sure what is happening there. That seems to be another issue entirely though.


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

#19
Posts: 2,740
Threads: 87
Thanks Received: 43
Thanks Given: 216
Joined: Jun 2009
Reputation: 25
Status
None
oh I just realized I have the merchant and ghost riding poses created already I can email those to you

also I was looking everywhere for Banon but I couldn't find it sorry, I'll just make one for you and send it your way eventually


"Sometimes ninjas do wrong to each other, and in dat way the force of tha earf' comes around da moon - and at that presence, da dirt, it overshadows the grass, so you're like, I can't cut dis grass, there's no sun comin' through. So in order to enable each other the two fruits have to look each other in da eye and understand we can only be right, as da ripe is wrong, you know what I mean?"

-HNIC
Quote  

#20
Posts: 579
Threads: 33
Thanks Received: 32
Thanks Given: 22
Joined: Jan 2015
Reputation: 9
Status
Dead
Got'em, thanks again.

On a semi related note, I need to recolor some of your other sprites. (I think they are all listed on the first post).

First, I do have to ask if its okay for me to recolor them to the default color palettes, hopefully without screwing up good looking sprites.

I finally got Egger's palette patch to install without crashing somehow (still not sure where the issue was, everything just started working and now I can't even force it to crash... pure dumb luck ftw) and need them to match the original NPCs after being inserted.

Second, there has got to be a better way of recoloring(well shuffling a palette index?) of a sprite rather than one pixel at a time. It has been awhile but I'm having no success what so ever getting an image editor to index a palette for importing. It keeps the palette, just never in the correct order. Even adding a palette map to the top of a sprite isnt keeping it in the intended order. Looks fine when I export it, looks fine in Gimp when I import it, looks fine when I adjust all the colors in Gimp, import it to a game editor and it looks like a bad acid trip...

In other words, anybody have a link to a tutorial on maintaining palette order during importing handy? Maybe I just forgot a step somewhere.


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



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite