Users browsing this thread: 1 Guest(s)
Expanded palette hack

#1
Posts: 45
Threads: 4
Thanks Received: 7
Thanks Given: 1
Joined: Jul 2013
Reputation: 4
Status
None
Author: Egger
version: 1.0
released on 09/12/2014
apply to a FF3us 1.0 headered ROM
Download
RHDN Entry

[Image: expal1.png] [Image: expal2.png] [Image: expal3.png]


This is a hack intended for those who are themselves creating ROM hacks. For those who are not themselves hacking the FF3/FF6 game, this patch will be of no interest. In fact, it will probably be difficult for non-ROM hackers to even understand what this patch does.

Specifically, this patch is intended for those who are creating or using new, custom sprites for new or altered playable characters. It allows the use of colors that, for strange technical reasons, were in the past not usable by any character who would participate in battle.

The included screen shots show the game's characters with altered colors. These characters are not using new or altered palettes. Each sprite is still using its original 16-color palette. However, these sprites are now using colors within that palette that previously were unusable. For instance, the pink color of Locke's shirt: in an unaltered ROM, if one tried to change Locke's clothing to this color by altering his sprite, his new sprite would not show up correctly in battle. It would show up with random, glitched colors. This patch allows these colors to show up correctly in battle, as pictured.

In essence, this patch expands the number of colors you can use for PCs, which gives you greater freedom in creating custom PC sprites.

Although this patch is easy to use in principle, the precise details of what it does and how it works are complicated, and are explained in greater detail in the readme file.
  Find
Quote  
[-] The following 1 user says Thank You to Eggers for this post:
  • Gens (04-23-2022)

#2
Posts: 2,768
Threads: 88
Thanks Received: 24
Thanks Given: 87
Joined: Jun 2009
Reputation: 25
Status
None
awesome to see you back eggers


"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  

#3
Posts: 2,548
Threads: 98
Thanks Received: 147
Thanks Given: 156
Joined: Aug 2009
Reputation: 52
Status
Nattak\'d
Just a heads up to any future people that may ever use this code/patch...

As quoted from the readme:
"The next time you enter battle, your new sprites will display correctly. You
may notice a short pause as the data is recalculated. That will only happen
the first time a sprite is used in battle after the cache is cleared, once for
each sprite."

This is normally no problem at all, as it only happens the one time the sprite data is loaded and is highly forgivable considering the awesomeness of the patch... but there is an exception of sorts, and it is Terra using Morph to turn into Esper Terra. If any of the last 4 colors are used on Esper Terra, or whatever character may have replaced her for your hack, it will do the "short pause" or lag each and every time she does the transformation/sprite change, and it is that much more noticeable and annoying lol. So the heads up is to simply avoid still not using the last 4 colors of the palette on Esper Terra to avoid this all together. That is all. Smile


We are born, live, die and then do the same thing over again.
Quote  
[-] The following 3 users say Thank You to Gi Nattak for this post:
  • Catone (11-24-2019), JWhiteLXXXIX (11-19-2019), SSJ Rick (12-02-2019)

#4
Posts: 82
Threads: 5
Thanks Received: 1
Thanks Given: 2
Joined: Jun 2014
Reputation: 2
Status
Medicated
So we get 4 extra colors per palette?
Quote  

#5
Posts: 77
Threads: 9
Thanks Received: 0
Thanks Given: 0
Joined: Jun 2016
Reputation: 4
Status
Slow
actually, the amount of colors you can use is still 11 per sprite, you just simply can use the last 4 in place of some of the normally used colors.
  Find
Quote  
[-] The following 1 user says Thank You to ScarabEnigma for this post:
  • Gi Nattak (11-25-2019)

#6
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
does the lag then happen on Reverting?
Quote  

#7
Posts: 2,548
Threads: 98
Thanks Received: 147
Thanks Given: 156
Joined: Aug 2009
Reputation: 52
Status
Nattak\'d
No sir, just when Morphing into the esper sprite, she reverts fine without lag. That's a good observation that slipped my mind, I woulda thought in hindsight that it would lag as well. I guess it has her regular sprite data stored and ready to load, but not her esper sprite, or something along those lines.


We are born, live, die and then do the same thing over again.
Quote  

#8
Posts: 200
Threads: 1
Thanks Received: 10
Thanks Given: 0
Joined: Oct 2015
Reputation: 18
Status
None
interesting.  yep, that's suggesting to me that plain and Esper Terras aren't sharing (and thus overwriting) a dataset here.  and in that case, is it possible that the sprite/palette cache simply doesn't include Esper Terra?  can it be expanded to do so?

so i decided to optimize the patch code:
http://assassin17.brinkster.net/forum-po...s-opt1.asm

*nothing* relates specifically to the issue at-hand here; it's just general speed-up attempts.  and very little of the changes demonstrate any grasp of graphics, so it's hardly an overhaul -- just based on experience with 65816 asm, and looking for redundancies and other opportunities.

main things changed:
- dropping unnecessary "REP #$20"s and "SEP #$20"s and such.  Eggers tended to put these right after A LOT of labels, almost like he wanted to readily say what the CPU mode would be at key points just to retain his sanity (it's a giant patch, after all), but then never went back to cull them.
- i don't think he was aware of the TSB instruction.
- nor CPY/CPX and BIT. Tongue
- weird stuff where he'd do:
1. enter 8-bit A mode
2. do 16- or 32- bits worth of memory storages
3. switch back to 16-bit A mode.
:O
- converting JMPs to BRAs, admittedly some enabled by my previous optimizations shrinking branch distances.
- in no particular category, i did overhaul the "lbg_palette_check_fill_with_ones" loop nicely.

---------------

someone let me know whether that .asm file assembles and runs properly.  if so, does it speed anything up?

the website with the assembler Eggers uses is down, and i'd be too lazy to download and run it anyway.

EDIT: okay, found the author has another website:
http://www.obelisk.me.uk/6502/downloads.html

---------------

what i'm focused on going forward are two things in the section from "lbg_replace_done" to "lbg_done_replacement_colors":

1. as you can see, i'm mulling optimizations from "EOR / STA" to TSB and to TRB.  it looks like i put each of those in the right spot based off his comments, but based on his actual code (there and at "lbg_find_unused_color" and "lbg_find_expanded_color"), i think i've got the instructions switched.  thoughts?

2.
Code:
JMP lbg_find_unused_color_pre        ; Return to the beginning of the loop

i half-think he wanted to do "JMP lbg_find_unused_color" there, based on:
a. the nature of most loops (e.g. not re-initializing an index to its starting value)
b. the way he preserves X right before looping
c. how he never branches to "[label_name]_pre*" -titled labels from below.  they're for loop setups as opposed to loop contents, apparently.

if i'm right, changing this one line could save as much time as my other dozens of optimizations put together!

thus, more scrutiny on "lbg_calculate_replacement_colors" through "lbg_done_replacement_colors" would be much appreciated.
Quote  
[-] The following 4 users say Thank You to assassin for this post:
  • Gi Nattak (11-26-2019), SSJ Rick (12-02-2019), Turbotastic (11-28-2019), Warrax (11-26-2019)

#9
Posts: 2,548
Threads: 98
Thanks Received: 147
Thanks Given: 156
Joined: Aug 2009
Reputation: 52
Status
Nattak\'d
Very nice optimization! I look forward to comparing and testing out the ASM and the code in-game.
Also I totally forgot to test Reverting from Morphed Terra with Terra using any of the last four colors >_<. I bet if she did use any of those it would lag each time on Revert as well... I'll test that just for the heck of it asap as well. Smile


We are born, live, die and then do the same thing over again.
Quote  

#10
Posts: 82
Threads: 5
Thanks Received: 1
Thanks Given: 2
Joined: Jun 2014
Reputation: 2
Status
Medicated
(11-24-2019, 11:48 PM)ScarabEnigma Wrote: actually, the amount of colors you can use is still 11 per sprite, you just simply can use the last 4 in place of some of the normally used colors.

That's kind of what I meant. I tried using them once and the colors changed in battle depending on your battle formation. But that's a massive boost in nice.
Quote  



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite