Users browsing this thread: 1 Guest(s)
Imp's Mapping (in development)
Serity was helping me work out a graphical mechanics problem... that is, the desire to have Imp status show on the map for the character.
Here's what I've got so far:
*Works on World Map
*Correctly reverts when Imp status is removed.
*Area Maps will display the wrong palette
I'm personally fine with the last one, but I know others might not be. As such, I thought I'd share the code here so others could work on it if they so desire.
The world map part is really straight-forward, in the EE bank we simply add a check for Imp status and then change the graphics of the 'map display character' in the RAM accordingly.
The field map part is more complicated. I've taken parts of the code that sets character graphics on a load, and injected them at a part of the C0 bank that runs more frequently. I've only done some cursory testing on this, so I'm unsure what its underlying complications might be.
EDIT: Forgot attachment. Note that the spaces used were free in my hack (which uses a slightly older version of the C.V. Reynolds bugfix compilation). That said, I hope these spaces are unused but I can't guarantee it. I apologize that the code is not more portable: I've annotated the one line that points to a specific address and would need changing if you need to move the used freespace.


Here's what I've got so far:
*Works on World Map
*Correctly reverts when Imp status is removed.
*Area Maps will display the wrong palette
I'm personally fine with the last one, but I know others might not be. As such, I thought I'd share the code here so others could work on it if they so desire.
The world map part is really straight-forward, in the EE bank we simply add a check for Imp status and then change the graphics of the 'map display character' in the RAM accordingly.
The field map part is more complicated. I've taken parts of the code that sets character graphics on a load, and injected them at a part of the C0 bank that runs more frequently. I've only done some cursory testing on this, so I'm unsure what its underlying complications might be.
Code:
==================================
Working Version 0_07! (No Field Palettes)
Imp's Mapping
==================================
C0/BD36: D65A
20 5A D6 JSR $D65A [Was B9 01 16, LDA $1601,Y]
C0/00E5: D767
20 67 D7 JSR $D767 [Was 20 A3 18, JSR $18A3]
C0/D65A:
B9 14 16 LDA $1614,Y [Current status of actor]
89 20 BIT #$20 [Is Imp bit set?]
D0 04 BNE skipAhead [Branch if so]
B9 01 16 LDA $1601,Y [Load saved character appearance]
60 RTS [Resume normal code]
A9 0F LDA #$0F [Load the Imp graphic]
60 RTS [Resume normal code]
C0/D767:
20 A3 18 JSR $18A3 [Execute original code]
48 PHA
5A PHY
DA PHX [Protect variables]
A6 00 LDX $00 [What's below recreates some of the draw functions used in a normal load]
9B TXY
[StartLoop]
20 5A D6 JSR $D65A [New subroutine that makes an Imp status check] ***Points to Freespace C0/D65A***
9D 79 08 STA $0879,X [Save the result as the character graphic]
7B TDC
A9 01 LDA #$01
C2 21 REP #$21 [This stuff is math to check if we've checked everybody... I think]
8A TXA
69 29 00 ADC #$0029
AA TAX
98 TYA
18 CLC
69 25 00 ADC #$0025
A8 TAY
7B TDC
E2 20 SEP #$20 [8 bit accum./memory]
C0 50 02 CPY #$0250
D0 E2 BNE StartLoop [Loop back to subroutine $D65A based on the result of the previous line]
[EndLoop]
FA PLX [Restore original variables]
7A PLY
68 PLA
60 RTS [Return to normal code]
EE/033F:
4C 01 AF JMP $AF01 [Was BD 01 16, LDA $1601,X]
EE/AF01:
BD 14 16 LDA $1614,X [Load status byte 1 of this actor]
89 20 BIT #$20 [Check if Imp bit is set]
F0 0E BEQ skipAhead [Branch if not]
A9 0F LDA #$0F [Load Imp actor graphic]
8D FB 11 STA $11FB [Store in graphics to display for lead character]
A9 05 LDA #$00 [Load Imp actor palette]
8D FC 11 STA $11FC [Store in palette to display for lead character]
A6 5A LDX $5A
80 0F BRA Exit
BD 01 16 LDA $1601,X [Load actor's character graphic]
8D FB 11 STA $11FB [Store in graphics to display for lead character]
A6 5A LDX $5A
BD 70 1F LDA $1F70,X [Load current actor's character palette]
4A LSR
8D FC 11 STA $11FC [STore in palette to display for lead character]
4C 4E 03 JMP $034E [Go back to normal code execution]
01-10-2021, 09:41 PM
Good stuff! I do hope the area map palette issue can get figured out, I am one of those people who could not live with that lol. It's great to see it in all its glory on the overworld for now at least.
One tiny tiny thing, I see in your posted code for the EE/AF01 part has the Imp palette as $05, and I'm fairly sure it means to be $00 which is the correct Imp palette. The actual patch seems fine though.
One tiny tiny thing, I see in your posted code for the EE/AF01 part has the Imp palette as $05, and I'm fairly sure it means to be $00 which is the correct Imp palette. The actual patch seems fine though.
We are born, live, die and then do the same thing over again.
Oop, you're right, that's the moogle palette! My bad.
EDIT: I'm stumped on the palettes. The Field Sprites don't set actor palettes in the way you'd think, it's three bits of data in the upper and lower portions of their sprites.
$0880 and $0881 in the Field RAM.
Character palettes are saved in $1F70-$1F7F, so I think the 'restore' function would need to call from there indexed based on the character, but every time I try the camera flies away and then the screen scrambles.
EDIT: I'm stumped on the palettes. The Field Sprites don't set actor palettes in the way you'd think, it's three bits of data in the upper and lower portions of their sprites.
$0880 and $0881 in the Field RAM.
Character palettes are saved in $1F70-$1F7F, so I think the 'restore' function would need to call from there indexed based on the character, but every time I try the camera flies away and then the screen scrambles.
01-15-2021, 11:26 AM
So if you're using FF3usME to set the palettes, there's actually an oversight in the way it does so in sprites above Umaro. If my memory serves me corectly, it affects the overworld as well. In the "Save Screen/Shop Palette Indexes" section, it shows 4 palette fields. However, because none of these sprites ever appear in the shop, there should actually only be 2 fields per sprite. That means that the palettes map like this:
1. Soldier's Top/Bottom Frame 1: Soldier Sprite (default 1)
2. Soldier's Top/Bottom Frame 2: Imp Sprite (default 0)
3. Imp's Top/Bottom Frame 1: Leo Sprite (default 0)
4. Imp's Top/Bottom Frame 2: Banon Sprite (default 3)
5. Leo's Top/Bottom Frame 1: Esper Terra Sprite (default 2)
6. Leo's Top/Bottom Frame 2: Merchant Sprite (default 1)
7. Banon's Top/Bottom Frame 1: Ghost Sprite (default 0)
8. Banon's Top/Bottom Frame 2: Kefka Sprite (default 2)
Under NO circumstances should you use the checkbox for "use the same indexes as the battle one" on any sprite above Umaro.
1. Soldier's Top/Bottom Frame 1: Soldier Sprite (default 1)
2. Soldier's Top/Bottom Frame 2: Imp Sprite (default 0)
3. Imp's Top/Bottom Frame 1: Leo Sprite (default 0)
4. Imp's Top/Bottom Frame 2: Banon Sprite (default 3)
5. Leo's Top/Bottom Frame 1: Esper Terra Sprite (default 2)
6. Leo's Top/Bottom Frame 2: Merchant Sprite (default 1)
7. Banon's Top/Bottom Frame 1: Ghost Sprite (default 0)
8. Banon's Top/Bottom Frame 2: Kefka Sprite (default 2)
Under NO circumstances should you use the checkbox for "use the same indexes as the battle one" on any sprite above Umaro.
Projects:
Divergent Paths: The 3 Scenarios (Completed) - a redo of the 3 scenarios in the original game that gives equal time to each group. Meant to be a basis for future mods.
FFVI: Divergent Paths (In Progress) - a hack built off of the 3 scenarios that changes other events in the same, such as making Leo permanently recruitable, bringing Banon's story closure, and adding 1 more secret character.
02-20-2021, 02:33 AM
Was the issue with the palette in the area maps ever resolved? I am using a new sprite for the imp in my hack, so it was perfect timing finding this patch. However, the wrong palette looks hideous on the new sprite I am using. I would actually prefer the imp only be enabled in world maps if the area maps cannot be fixed! This would be better than nothing at least!
(02-20-2021, 02:33 AM)Lightning Wrote: I would actually prefer the imp only be enabled in world maps if the area maps cannot be fixed! This would be better than nothing at least!
You'd just need to revert these two JSR back:
C0/BD36
C0/00E5
They are for the normal maps, while the JMP at EE/033F is for the overworld.
We are born, live, die and then do the same thing over again.
Yeah, I'm having heaps of troubles with setting and resetting palettes for imp'd status on the field map. I was able to get it working for Terra, but only for Terra and only through hard-coding the original and destination palette. Which would mean that characters--when imp'd and reverted--would be returned to a pre-determined palette, rather than whatever palette was last set for them in the event script.
This is because the game code is constantly writing the current field palette as the 'saved' palette to the save RAM. Other than setting up a second set of SRAM bytes for the player characters and saving and referencing them separately (which I'm not sure I could do, and which would cause problems anyway if imp'd during a cutscene that changes palettes), I'm not sure I can get around this.
EDIT: Maybe it could be stored in out-of-battle status $04... it always gets scrubbed down to Float and Dog Block when referenced by the battle engine, so perhaps palette could sit there? EDIT: Nope, that's not going to work. I need another register, dangit! I'm not good enough to code this.
EDIT: In case someone wishes to pick up where I left off, here's what I've learned.
> For Field Sprites, both $0880 and $0881 need to be updated with a new palette. Palette bits are $0E on both of them, you'll want to scrub that by ANDing them with $F1 (possibly storing the result), then OR them with your desired new palette (2*Palette #), and store the result over the original.
Y does skips by 37 and is to be used to check the character statuses ($1614 and $1615). X does skips by 41 and is to be used to change the character field properties ($0880 and $0881)
Below is my code brainstorm. I could not get to execution because I could not think of a viable way to save field palettes ($1F70 through $1F7F) to $1615,Y. The former would have to be loaded in increments of 1, which I can't do because X must load in increments of 41 and Y must load in increments of 37... hence my complaint that I needed another register.
This code brainstorm is intended as a starting point. DO NOT JUST PLOP IT INTO A ROM, IT WILL NOT WORK! If anyone cares to explore the matter further, that's the extent of my understanding. Getting Terra to switch back and forth from two fixed palettes is easy, but getting the entire cast to switch back and forth from a saved palette and the imp palette is a nightmare.
This is because the game code is constantly writing the current field palette as the 'saved' palette to the save RAM. Other than setting up a second set of SRAM bytes for the player characters and saving and referencing them separately (which I'm not sure I could do, and which would cause problems anyway if imp'd during a cutscene that changes palettes), I'm not sure I can get around this.
EDIT: Maybe it could be stored in out-of-battle status $04... it always gets scrubbed down to Float and Dog Block when referenced by the battle engine, so perhaps palette could sit there? EDIT: Nope, that's not going to work. I need another register, dangit! I'm not good enough to code this.
EDIT: In case someone wishes to pick up where I left off, here's what I've learned.
> For Field Sprites, both $0880 and $0881 need to be updated with a new palette. Palette bits are $0E on both of them, you'll want to scrub that by ANDing them with $F1 (possibly storing the result), then OR them with your desired new palette (2*Palette #), and store the result over the original.
Y does skips by 37 and is to be used to check the character statuses ($1614 and $1615). X does skips by 41 and is to be used to change the character field properties ($0880 and $0881)
Below is my code brainstorm. I could not get to execution because I could not think of a viable way to save field palettes ($1F70 through $1F7F) to $1615,Y. The former would have to be loaded in increments of 1, which I can't do because X must load in increments of 41 and Y must load in increments of 37... hence my complaint that I needed another register.
Spoiler (Click to View)
« Next Oldest | Next Newest »
Users browsing this thread: 1 Guest(s)