øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=278;area=showposts;start=195e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index4622.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=278e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index4622.html.zx¾åg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈà·ÿOKtext/htmlISO-8859-1gzip0|Ö·ÿÿÿÿÿÿÿÿÿTue, 10 Mar 2020 19:25:09 GMT0ó°° ®0®P®€§²ð®½åg^ÿÿÿÿÿÿÿÿN(·ÿ Show Posts - chillyfeez

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - chillyfeez

196
Final Fantasy IV Research & Development / NPC Priority?
« on: May 27, 2016, 12:37:07 PM »
You know how when two NPCs are standing on the same spot, the game has to choose which one is fully visible and which one is masked?
Anybody know his the decision is made?
Is there a way I can force a specific NPC to appear on top of the other?
Is it the order that they are on the list of the location's NPCs?
Does it depend on which one was in that spot first?
Something else?
 :hmm:

197
To confirm the above suspicion, events do call these sound effects as well. The "jumping down the waterfall" event uses "prolonged falling sound."

Come to think of it, isn't there some kind of ticking clock sound in Cecil's room in the beginning of the game just before Rosa shows up? That's not on my list here, but I'll bet it's one of these...

198
Final Fantasy IV Research & Development / Background Sound Effects
« on: May 23, 2016, 11:39:50 AM »
So I'm working on the Watery Pass in TfW and I stumbled upon some info that, as far as I know, hasn't been documented yet.

Ever notice that when you enter the Waterfall on the way to Octomamm, that first screen (before jumping down the waterfall) doesn't have music, but just a running water sound?

Turns out, the "music" byte for that map is set at 44. But, songs in FFIV are only numbered up to 37. So I isolated this byte and did some experimenting. Here's what I came up with...
Code: [Select]
38 through 3D - NOTHING
3E - PROPELLER SOUND (FADES IN)
3F - THREE GONGS, SHIP WHISTLE BLOWS (I THINK WHEN THE SHIP TAKES OFF FROM FABUL)
40 - A DISTANT CRASH SOUND
41 - A NOT-SO-DISTANT CRASH SOUND
42 - EARTHQUAKE
43 - PROLONGED FALLING SOUND (PERHAPS USED WHEN CID BOMBS THE ENTRANCE TO THE UNDERWORLD?)
44 - RUSHING WATER (WATERFALL)
45 - NOTHING
46 (and above?) - CRASHES GAME

Not a whole lot of useful stuff here, but maybe someone will be interested.

FF4kster doesn't have the ability to set these bytes above the last song (Ending 3), so you'd have to isolate and change the byte manually. For a shortcut to doing this, set an Execute breakpoint to 00/83EF, then enter the location whose music you want to change. 83EF will execute 12 (0C) times. You'll see the Y register increment by 1 each time. When Y = 0007, the byte being read is your music byte.

I imagine these sound effect "songs" can be called via event instructions, too, but doing so would likewise be impossible with FF4kster. Describing a similar shortcut to manually change these would be a bit more difficult, too, because of the way the game loads event instructions.

199
Regarding sick, twisted ideas... You could change the slime monsters into poo.
Brown poo, green poo, white (bird) poo. You could put flecks of different colors in the monster sprites, then using the palettes to your advantage they could sometimes be the same color (like for solid brown), but sometimes be a different color (say, for a monster called "With Nuts" or "With Corn").

... Apologies to anyone reading this who has a weak stomach.

200
I think fedorajoe must have typoed and meant to say AB4FA.
And that's with a header, so AB2FA if you're unheadered.

201
So, as I mentioned in another thread, I've been working on some stuff for the Octomamm battle, which will be (probably) at the end of the next release.

Here's a video of what it'll be like

There are still a couple of minor details to iron out - mostly AI related - but you can get the picture anyway.

If you're wondering why Rydia and Cinna don't cast magic once all of the tentacles are defeated, it's because doing so causes Octomamm to regenerate all six tentacles (with reduced HP, but still...). I kinda wanted to show that, but I didn't want the video to run too long.

202
The zoomy effect is Mode 7 in action, and I'm pretty sure location maps exist on the wrong background layer for that to be a possibility (the same reason you can't fly an airship in a location map).

As for the pixelization effect, that is a specific capability of SNES's graphics processor. I think it can be manipulated to some degree, but I don't really know how. Documentation I've found on SNES graphics processing reads like stereo instructions (pardon the dated expression). It's generally taken me weeks to figure out things that seem much simpler than that.
But if you wanna take a crack at it, here's the documentation I've found:
http://emu-docs.org/Super%20NES/General/snesdoc.html#BGBasics
Bear in mind that this is just info on how SNES graphics works, and contains nothing specific about FFIV.

203
Okay, never mind...
Those two bits work exactly the way I thought they did, it was my hacking that was lacking (pardon the seussism).

For the record:
00: finger and flash react according to the rectangular size of monster type 1
10: finger and flash react according to the rectangular size of monster type 2
20: finger and flash react according to the rectangular size of monster type 3
30: unused

I'm not sure I'll ever understand why the programmers found these two bits to be necessary. The game already references the monster type before running the subroutine that looks at them, so there should be no question which monster type is flashing, or whatever...
 :wtf:

Any who, I got working what I needed to. I'll put up a video of the Octomamm battle once I have the monster stats and AI all set. Might be a while, though, because I'm taking a little time off.

204
OK, so as I've discussed previously, there is a table of five-byte entries at 7CE00 (FCE00 in LoROM) that controls the details for monsters' special sizes (when size byte is set as 80 thru BF).
Here's what I know for sure:
Byte 0:
 Upper four bits: x-position
 Lower four bits: y-position
Byte 1:
 Lower six bits: pointer to actual rectangular size (in size table at 6FF5E)
Byte 2: Palette
Byte 3:
 Lower four bits: transition style (as detailed by avalanche here)
 Upper two bits: indicates which monster type in battle is affected by a transition command performed by that monster in battle
Byte 4: Tile arrangement pointer

So, the remaining mysteries here are...
- the upper two bits of byte 1
- bits 4 and 5 of byte 3

I don't really care much about those bits in byte 1. So far I haven't seen anything that references them.
What I am trying to figure out is the specific use of those two mystery bits in byte 3.
They do something, and it's graphical. That much I know. Near as I can tell, it has something to do with how the game treats the monster's rectangular size. That is, it doesn't affect the actual size itself, but it affects the position of the finger cursor when pointing to the monster, and it affects which tiles blink when the monster attacks or has magic cast on it.
In battles that feature multiple special-sized monsters, the different monsters have different values, but different forms of the same monster have the same value. So, none of the Octomamm forms have any of those two bits set; but Sandy, Cindy and Mindy are 00, 10 and 20, as are Baigan, Left Arm and Right Arm.
Finding out the exact nature of these two bits has become kind of important to me. I'm up to the Watery Pass in my hack, and I'm reimagining Octomamm in a way that really makes use of hacking the battle system. Basically, he's going to have six independent arms - three that use magic and three that use physical attacks - and they will constantly shuffle between seven different positions throughout the battle. The problem with all this is that, based on a lack of understanding of those two bits, their attack flash (and getting attacked by magic) sometimes does not make the entire tentacle flash. It's just an aesthetic thing, but it's really bugging me.
I doubt this is a thing that can be solved with just experimentation, though I'd welcome anyone who wants to try. It probably will require somebody watching a live disassembly of a read on that byte. I've tried that, but I haven't been able to figure out what I need to know.

Anyway, if anyone reads this and has any ideas or motivation to help - thanks!

205
So, to confirm what I think you're saying...

When in a world map, there are 256 (0x100) 8x8 tiles loaded into VRAM (which is different than locations, which only have 128 per tileset), but those tiles are palette-locked per the data at A0600, one byte per tile*

Then the table at A0000 assigns four of those 256 8x8 tiles to each 16x16 tile, one corner at a time (so all the top lefts, then all the top rights, etc). It seems, then, that there would be no way to flip vertically or horizontally, either, and no layering, right?

* I don't really know much about how SNES processes graphics, so forgive my noobiness here... I know the world map tiles use some different variant of 4bpp, wherein the 0x20 byte palettes function sort of like two independent 0x10 byte palettes. I know that bcause of experiences messing with the live RAM data. Do those palette assignment bytes actually assign two 0x10 byte metapalettes, or are there several 0x20 byte palettes that simply have common data?

206
I donno, sorry. It's something I'll need to figure out eventually, but haven't  needed the info yet. I have to figure the "tile assembly" works somewhat differently than the location tiles, as those use two bytes per corner and include tile assignment and palette in each of those two bytes. Judging by those offsets, the tile assembly must be 0x80 bytes per corner, thus one byte per tile. Then two bytes per tile for the palette assignment table?
I won't have time to experiment with this for a few days, but I will when I get the chance if nobody swoops in before I do.

207
Final Fantasy IV Research & Development / The Pseudorandom Array
« on: April 18, 2016, 05:51:14 PM »
I don't think I've ever seen it documented anywhere, but this is interesting and pretty useful for custom stuff.

At startup, the game copies 6/EE00 (in ROM w/o header, or 14/EE00 in LoROM) through 6/EEFF into 7E:1900-19FF in RAM.

These 100 bytes are the effective random number array that (I think) is used for all random number generations. There's a constantly rotating byte - 67A out of battle and 097 in battle - that gets loaded into X, then we load 1900,X into A to get our pseudorandom number.

Theoretically, the game could just load 14/EE00,X every time, but it takes one less byte each time to use the array in RAM. Still, seems like an odd way to occupy those hundred bytes of RAM...

208
You would have to change one of the four PC palettes so that it was the same as the blue townsfolk palette. While it may be possible to reroute the palette loading code so that Yang uses a townsfolk palette, there are more than four townsfolk palettes, and they change depending on the location (part of the map data is an assignment of two "NPC palettes" that are each actually two palettes each, so that each map has four palettes, but not necessarily all the same four).

209
Does he have a spell called "Diabeatiss?"

210
Assuming your ROM has a header...
*Take the offset of the first tile the monster uses (can be found in TLP, probably YY-CHR too, I guess).
*Subtract 8000 (hex)
*divide by 8
*convert the hex result to decimal

For instance:
*Imp begins at 68818
*68818 - 8000 = 60818
*60818 / 8 = C103
*convert to decimal: 49411