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

#51
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
[Image: 6d4barnnnrxpr2yzg.jpg]

The latest batch of imported sprites: Rachel, Suited Gau, Vargas.

Main reason for the particular screen shot was to see the original Rachel sprite (top)next to the new one (second from top) side by side on the field of battle.

Truthfully, I still like how the original looks with the brighter colors, but the new version defiantly matches the vanilla more accurately. Not that I'm complaining either way, being torn between which to use is a good situation to be in.

Next on the agenda, portrait tables. Forgot I never got that done before. In the very least I have to have something show up in the menu other than garbage/glitched pixels so it has to be done.


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

#52
Posts: 89
Threads: 2
Thanks Received: 2
Thanks Given: 1
Joined: Jul 2009
Reputation: 5
Status
Vampire
Thank you for testing them. My real goal is to try and stick with as vanilla as possible and have all the animations as professionally done as i can. I do have to improvise a bit to get 12 colors on some of these but still. With an updated sprite one does have the option of using palette 0 and doing the blue hair and such the sprite itself is more up to date (after reducing the "big innocent girl eyes" because the blink animations looked bad, i had to fix her newly obtained massive forehead lol).

I also see that thats an older version of suited Gau, (the other shade of blue didnt load)
I'll re upload them to the gallery for the sake of having the files saved somewhere.

Also about the "portrait" thing. for such a massive amount of sprites i bet its still easier to set the portrait to that special unused pose slot by the tent of the pc sprite. I personally would rather have that than a bunch of non matching portraits...
  Find
Quote  

#53
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
Wouldn't have to use any part of the sprite sheet to make a "portrait" sprite, portraits are an entirely seperate (even if your using a custom sprite as a portrait).

The real problem there is how the palettes are handled, for all normal intentions, every portrait has its own full palette. Not sure if thats possible for 100+ portraits. Still not sure how they read/load that data. Worst case, all of the upper sprites might have to have a shadowed siloette as a portrait to not seem out of place.


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

#54
Posts: 89
Threads: 2
Thanks Received: 2
Thanks Given: 1
Joined: Jul 2009
Reputation: 5
Status
Vampire
thats too bad about the palettes for extra portraits its a shame they cant just be pointed to their own sprites palette.
  Find
Quote  

#55
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
It MIGHT actually be possible to point all the portrait palette table calls to the sprite palette table (then the same for the pointers to the palettes themselves (may even eventually try it just to see if it works). But have another plan in mind at the moment, just spent 2hours laying the ground work for the process (regardless of how it gets done in the end) well most of it anyway.

Also have another plan (that I'm probably gonna hate myself foreven thinking of) on how to handle something, depends on how things do or do not do what I tell them to as to how far that goes. Still, its a plan that should float (haven't drilled any hole in the bottom of that boat yet, so it shouldn't sink).

Will have to see how it goes, if I can at least get all the code wrote and working it'll just be a matter of importing and formatting. At that point if I'm forced to stop work on it, it shouldn't take to much to remember how to do that part. In other words at that stage it may become a project that takes to long, but the possiblity of it becoming a dead one drops greatly (talking worst case here).


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

#56
Posts: 3,966
Threads: 279
Thanks Received: 234
Thanks Given: 56
Joined: Oct 2011
Reputation: 65
Status
Tissue-aware
The table at C3/6F00 is the portraits palettes offsets. You could instead load the SRAM sprite ID of the character and load the palette/portrait offset based on that value. Right now for palettes it's just a basic offset calculation (shown below). That value is then used at C3/6C41 and C3/7D05.

The table for portrait offsets is at C3/6F1B and an entry is a two bytes pointer based on the first portrait location in the ROM ($ED1D00). If you expand and relocate the portrait, some portion of code add #$1D00 to the table entry while others use the C3/7000 routine. Just search for "C36F1B" to get the place where the portrait offsets table is used.

I hope I didn't just repeated stuff you already knew :/

Code:
C3/6C31:    BF006FC3    LDA $C36F00,X    (load palette table entry)
C3/6C35:    C220        REP #$20          (16 bit memory/accum.)
C3/6C37:    0A          ASL A
C3/6C38:    0A          ASL A
C3/6C39:    0A          ASL A
C3/6C3A:    0A          ASL A
C3/6C3B:    0A          ASL A
  Find
Quote  

#57
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
Only some of it, already have a portrait list #112 long and a palette list with #112 palettes to match as of 6am this morning.

That being said, your idea of using the sprite ID should work as well, (maybe even better) but the math seems to work out just redirecting it to the new list (takes whatever the palette number is from the list and multiplies it to create an offset). Only real problem that showed up with the vanilla math was the portrait offset table only has a 2 byte adress which only leaves room for about 82 or so portraits (normally that would be plenty wouldn't it? LOL) Anyway, as is, as long as it doesn't overflow somewhere if I try to load sprite #104 it should work. Since stuff like Owzer, theBlackjack, and the two-top and bottom halves of monsters that Odin meets in the flash back have no practical or semi-practical use for a portrait, I plan on using 81 portraits filling one bank, and save the last for a shadowed sprite filler, just in case, so it still won't display glitched pixels.

In other words, can't justify changing the code to read a 3 byte address. Worst case could probably check the sprite ID and branch to one of two tables for two banks worth of portraits but... don't see it being needed.

What I still find interesting is that the palettes for portraits are still 16 colors, but load 2 bytes at a time meaning 32byte color palettes for portraits (still 16colors though).

Sprites still load 1 byte a pass though. (This based on watching the debugger for a few hours and the fact that dropping 16 bytes at an address for a portrait palette leaves nasty results.

Also don't get why it sometimes uses the direct address at C3/7000 and another time it sets the bank independantly, and adds the $1D00 to the value from the table. A few other times it just accesses it directly. Either way other than several pointer changes, having them start at an even bank of 51/ for portraits, 52/ for palettes. Could still do something stupid like have battle palettes listed at 53/ (which will load battle palette #41 from there...) but thats a whole other deal.


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

#58
Posts: 3,966
Threads: 279
Thanks Received: 234
Thanks Given: 56
Joined: Oct 2011
Reputation: 65
Status
Tissue-aware
(12-12-2015, 12:51 PM)catone Wrote: Only real problem thst showed up with the vanilla math was the portrait offset table only has a 2 byte adress which only leaves room for about 82 or so portraits

That's right. I think the offset calculation based on ID * $320 is also a neat solution. In case of overflow you add 1 to the bank value. That would leaves you with 160+ possible entries, assuming you got 160 sprite (as far as the turtle portrait XD).


(12-12-2015, 12:51 PM)catone Wrote: What I still find interesting is that the palettes for portraits are still 16 colors, but load 2 bytes at a time meaning 32byte color palettes for portraits (still 16colors though).

Yes, a SNES color is 15 bytes. The format is ?bbbbbgg gggrrrrr. It would pretty dumb from Square not to use 16 colors, based on the fact that every SNES sprites are 16 colors, even those that have a 8 colors palette (they're just not using the full potential).

(12-12-2015, 12:51 PM)catone Wrote: Also don't get why it sometimes uses the direct address at C3/7000 and another time it sets the bank independantly, and adds the $1D00 to the value from the table.

This and also [absolute loading, such as LDA $C2/6F4D,X] vs [X value based on bank value independently loaded of inner bank starting offset] is done differently for the same stuff in the game code, such as font loading. I'm thinking it might has to do with flags already set or register values that are already there and in some case they realized they are saving two bytes of space by doing it the other way, but that's just a quick theory based on nothing really.
  Find
Quote  

#59
Posts: 89
Threads: 2
Thanks Received: 2
Thanks Given: 1
Joined: Jul 2009
Reputation: 5
Status
Vampire
Sidebar, this mass sprite sheet thing makes me think of the romancing saga series where so many alternate characters were available for your final party. but how will the ending look with these swapped characters?
  Find
Quote  

#60
Posts: 676
Threads: 44
Thanks Received: 26
Thanks Given: 21
Joined: Jan 2015
Reputation: 11
Status
Zombie
Heh, that's an issue I'm currently avoiding thinking of on many levels.

Even at the start I knew there would be alot of issues created by doing so much, then the more that gets added, the bigger the issues. Saddly without alot of event editing in alot of different places, this is going to break most of the game, least event wise. Frankly its just become to big of a monster for me to think of the whole project at one time.

Of course, if I were to edit all of the events to make them work with this, it would overwrite anything else that was done by the user. So the key fixes to events will be done after this is complete'ish as a sepperate patch to "fix" some of the game it breaks. The main goal is still for someone/anyone else besides me to use it, so I don't have any intention or desire to actually work this patch into the game myself, at best fix just enough to make it to where it doesn't make the game unplayable and let who ever wants to go from there.

And I forgot about the turtle and rat being way up there in numbers. Hrm, will have to count if 81 is enough to spread around. It might actually require 2 banks.


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



Forum Jump:

Users browsing this thread: 3 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite