Users browsing this thread: 1 Guest(s)
Imp's Mapping (in development)

#1
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
EDIT: Release Version!  Let's call it Version A.
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.

Surprised Kappa!

Here's what I've got so far:
*Correctly reverts when Imp status is removed.
*World, Field, and Battle will display imp, in the palette of each character.
*Imp Graphic has to be altered to look acceptable in all 7 battle palettes.


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.
And the battle part is the most complicated.  The update character sprite/palette function had to be replicated in a separate spot for the Imp call.  I tried to manage this with a less byte-intensive method, but I couldn't sieve out all the spots I needed to catch and flag a 'normal' draw verses an imp draw, which was resulting in palette errors.

Special compatibility consideration must be made if using this code with LeetSketcher's Imp Skimp.  The ips patches included in the package that are Imp Skimp compatibility already have Imp Skimp included, including the 'dead draw' correction mentioned in another thread.  You can also consult the included .asm files to see the difference.

Also included are recolors of the Imp sprite made by Lightning for the purposes of this code.  If you're looking to just plug and play, use the GFX version of the patch you want.


Attached Files
.zip  ImpMap.zip (203.06 KB, 6 downloads)
  Find
Quote  
[-] The following 5 users say Thank You to C-Dude for this post:
  • Gi Nattak (01-10-2021), Lightning (02-20-2021), madsiur (01-11-2021), SSJ Rick (01-16-2021), Warrax (01-10-2021)

#2
Posts: 2,548
Threads: 98
Thanks Received: 147
Thanks Given: 156
Joined: Aug 2009
Reputation: 52
Status
Nattak\'d
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.


We are born, live, die and then do the same thing over again.
Quote  
[-] The following 1 user says Thank You to Gi Nattak for this post:
  • C-Dude (01-10-2021)

#3
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
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.
  Find
Quote  

#4
Posts: 614
Threads: 49
Thanks Received: 0
Thanks Given: 4
Joined: Feb 2017
Reputation: 25
Status
None
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.


Projects:
FFVI: Divergent Paths (Completed) - a complete storyline and gameplay hack of FF6 that adds Leo as a playable character
  Find
Quote  
[-] The following 1 user says Thank You to PowerPanda for this post:
  • SSJ Rick (03-13-2021)

#5
Posts: 311
Threads: 20
Thanks Received: 0
Thanks Given: 0
Joined: Dec 2017
Reputation: 2
Status
None
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!
  Find
Quote  

#6
Posts: 2,548
Threads: 98
Thanks Received: 147
Thanks Given: 156
Joined: Aug 2009
Reputation: 52
Status
Nattak\'d
(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.
Quote  
[-] The following 1 user says Thank You to Gi Nattak for this post:
  • Lightning (02-20-2021)

#7
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
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.
  Find
Quote  

#8
Posts: 377
Threads: 34
Thanks Received: 10
Thanks Given: 7
Joined: Dec 2018
Reputation: 18
Status
Moog
Lightning and I discussed it, and we decided the better approach was to embrace the character palettes rather than try to fight them to get the Imp to display.  It was actually much easier to get the character palette to show with imp status in battle than it would have been to show the imp palette in the field maps.

As such, I am updating this patch to version 1_0.  See the attachment in this post.

This was tested in a 1.0 ROM, but no changes are made in the C2 bank so it should be compatible with 1.1 ROMs as well.  No promises, though!

EDIT: Lightning looked into it, and the 1.1 ROM is transposed back 3 bytes in the section of C1 that is edited by this code.  So it will not be compatible without customizing the .asm.  Basically, all the pointers in the C1 sections of the code have to be reduced by 3.  Also, I was trying to be clever to save space and I broke it (couldn't set the scratch variable in all the spots it needed).  Lastly, we found an incompatibility with LeetSketcher's Imp's Skimp, which I'm working to fix.

EDIT: Tentatively have a working patch repository with options for FF3US 1.1 AND ImpSkimp compatibility.  Going to wait to release a package for now; need time to double-check and to collect it.

EDIT: Patch package is ready, see the first post!
  Find
Quote  
[-] The following 1 user says Thank You to C-Dude for this post:
  • Lightning (03-19-2021)

#9
Posts: 311
Threads: 20
Thanks Received: 0
Thanks Given: 0
Joined: Dec 2017
Reputation: 2
Status
None
I forgot to say thanks for this patch! It really is a nice addition to my hack. Smile
  Find
Quote  



Forum Jump:

Users browsing this thread: 1 Guest(s)


Theme by Madsiur2017Custom Graphics by JamesWhite