Author Topic: Character Graphics Swap hack.  (Read 4855 times)

Mauron

  • Guru of Reason
  • Errare Explorer (+1500)
  • *
  • Posts: 1592
  • Nu-chan
    • View Profile
    • Maurtopia
Re: Character Graphics Swap hack.
« Reply #60 on: September 19, 2020, 01:27:40 am »
Yeah, I forgot that part. It makes them trickier to work with.

IHBP

  • Architect of Kajar
  • Enlightened One (+200)
  • *
  • Posts: 295
    • View Profile
Re: Character Graphics Swap hack.
« Reply #61 on: September 19, 2020, 08:59:16 am »
Code: [Select]
242600 242783 PTR N "Pointers to character animations (?) (local, first at 243000)" 2004.06.21
242800 242983 PTR N "Pointers to unconfirmed animation data (local, first at 24A800)" 2004.06.21

Two byte local pointers for these.

I saw this in the offset notes but couldn't make sense of it, why are there two sets of pointers? what is a two byte pointer?  I did find out that the last used animation index is 191 so the new data should go in 192 (C0)

What I imagine I have to do is identify Glenn's animation data, export it, then add it to the end of the existing animation section without repointing it?

Also does anyone know who actually made human Glenn for FoE? I'd like to get their permission to use this.
« Last Edit: September 19, 2020, 10:25:49 am by IHBP »

Mauron

  • Guru of Reason
  • Errare Explorer (+1500)
  • *
  • Posts: 1592
  • Nu-chan
    • View Profile
    • Maurtopia
Re: Character Graphics Swap hack.
« Reply #62 on: September 28, 2020, 04:14:12 pm »
Two byte pointers can address xx0000-xxFFFF, with xx being defined elsewhere and the same for all of them. In the case of animation data, the xx is 24 (E4 to the SNES).


I haven't done as much with animations, so I've gotten rusty on some of that. Here's an old note from Vehek:

Quote
242800   242983   PTR   N   "Pointers to unconfirmed animation data (local, first at 24A800)"   2004.06.21
A while ago, I looked at this and concluded that the unconfirmed animation data is the frame length for the animations.

Yesterday, I tried to figure out where individual animations start by watching how the menu does it.
Starting at the beginning of the animation data for a direction, animation x starts at 4 * x. This explains why glitch animations exist and why there are 00's between many animations.

Also, the game finds the size of the animation data by looking at the pointer for the next animation data. It then divides it by 4, which I think is to find the size of each direction's animations.

IHBP

  • Architect of Kajar
  • Enlightened One (+200)
  • *
  • Posts: 295
    • View Profile
Re: Character Graphics Swap hack.
« Reply #63 on: October 06, 2020, 07:16:05 pm »
Sorry I haven't had a chance to do any hacking for a few days.

Now that I better understand how the animations and their pointers work I was able to do some investigating to try to fix the graphical problems.  Turns out that the animation data for Glenn is the same as Frog's vanilla data.

So animations dont need to be altered to have a working Glenn,   the sprite assembly seems to be vastly different so I imported the entirety of it into my rom in the vanilla location and set Frog back to Sprite assembly 04 but Glenn is still very glitched even with 100% of FoE's Sprite assembly data (even did a rom comparison to make sure they were identical. )

I also checked the rom in a tile editor and all the Glenn graphics were imported properly, but all I can get it to display in game is what's shown in this video.



https://www.dropbox.com/s/xk9mpj9u3qy9nvl/20201006_175416.mp4?dl=0



Mauron

  • Guru of Reason
  • Errare Explorer (+1500)
  • *
  • Posts: 1592
  • Nu-chan
    • View Profile
    • Maurtopia
Re: Character Graphics Swap hack.
« Reply #64 on: October 07, 2020, 07:58:19 pm »
Send me the latest patch, I'll look at it.

IHBP

  • Architect of Kajar
  • Enlightened One (+200)
  • *
  • Posts: 295
    • View Profile
Re: Character Graphics Swap hack.
« Reply #65 on: October 08, 2020, 12:01:29 am »
Here's my latest build, Frog is using the "Glenn" settings by default on this one.

Something interesting,  if you get into a battle it uses Frog's graphics again ( minus his palette)

https://www.dropbox.com/s/y48coclpi41axaq/CT%2B%202.5beta.ips?dl=0

Vehek

  • Errare Explorer (+1500)
  • *
  • Posts: 1711
    • View Profile
Re: Character Graphics Swap hack.
« Reply #66 on: October 09, 2020, 03:15:42 am »
I was going to write this earlier before I changed my mind.
One of the quirks of the engine is that in some cases, it's programmed to load PC graphic data only from the original PC graphic banks. When it's given an address outside them, it defaults to bank D5, the one containing Ayla. I think there might have been a patch for this, but I'm not sure.
Something interesting,  if you get into a battle it uses Frog's graphics again ( minus his palette)
Another one of those spots where it ignores the sprite data entries, instead using the PC index.

IHBP

  • Architect of Kajar
  • Enlightened One (+200)
  • *
  • Posts: 295
    • View Profile
Re: Character Graphics Swap hack.
« Reply #67 on: October 09, 2020, 10:42:56 pm »
That makes sense, there was a similar situation with the palettes.

Mauron

  • Guru of Reason
  • Errare Explorer (+1500)
  • *
  • Posts: 1592
  • Nu-chan
    • View Profile
    • Maurtopia
Re: Character Graphics Swap hack.
« Reply #68 on: October 10, 2020, 01:17:13 pm »
I forget if we have a stand alone patch for the graphics loading.

I'm going to have to organize some of those graphic fixes to get it consistently using sprite data.

Mauron

  • Guru of Reason
  • Errare Explorer (+1500)
  • *
  • Posts: 1592
  • Nu-chan
    • View Profile
    • Maurtopia
Re: Character Graphics Swap hack.
« Reply #69 on: October 11, 2020, 11:18:18 pm »
I thought we had a graphics loading patch in IHBP's ROM, but I was wrong about that. Adding that got everything but a few frames working perfectly.

I'm working on the battle portion next.

IHBP

  • Architect of Kajar
  • Enlightened One (+200)
  • *
  • Posts: 295
    • View Profile
Re: Character Graphics Swap hack.
« Reply #70 on: October 12, 2020, 12:56:18 pm »
That's really good news, I'm glad that it's not the Sprite assembly that's the problem.