øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=278;area=showposts;start=555e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index19f8-3.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=278e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index19f8-3.html.zxÉåg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ0P.ÖOKtext/htmlISO-8859-1gzip8:ÖÖÿÿÿÿÿÿÿÿTue, 10 Mar 2020 19:25:20 GMT0ó°° ®0®P®€§²ð®Éåg^ÿÿÿÿÿÿÿÿþ&Ö 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

556
Can anyone think of any events that use the "move camera up one space then down again" instruction?

That seems like a silly one that could be easily changed to something else with very few consequences...
Though it has no natural parameters...

557
I'm curious as to what the presumed function of that instruction would be, PinkPuff, considering the fluidity of party slots?

I remember what I wanted as an event instruction now. It was, "reduce HP by XX."
I ended up putting some event-specific ASM in my hack to reduce party HP whenever a particular event occurs instead.
Wouldn't it make sense, for example, for the "Ouch!" event to reduce HP? That's not what I wanted it for, but it's a relatable example.

558
Final Fantasy IV Research & Development / Re: 4bpp Graphics Backport
« on: March 17, 2015, 09:08:38 AM »
Pretty soon you'll be able to do a completely new game with its engine.   :D
Working on it... Slowly but surely ;)

559
I actually had no idea there was an unused event code.
I was thinking to myself recently that I wished there was, but then I just shrugged it off. Now I can't remember what I wanted it for... Oh well, good to know.
Good stuff, Grimoire.

560
Final Fantasy IV Research & Development / Re: Japanese Title Screen
« on: March 08, 2015, 11:57:51 PM »
Yeah, I've been using that, too. I don't think I realized it was right after the title screen image data.
I suppose at some point I'll get to looking at the Japanese ROM to check all this out.
I hope I don't get any crazy ideas. I'm perfectly happy not being interested in title screens...

561
Final Fantasy IV Research & Development / Re: Japanese Title Screen
« on: March 08, 2015, 08:05:30 AM »
Huh. Interesting. Does the Japanese title screen data fit into the same place in ROM when spliced into the US version?

Any suggestions for resources I can direct this fellow to to study up on this stuff?
TBH, I don't have a whole lot of interest in SNES title screens. In my mind, I'll go a loooong time before I ever need to edit one again for my own purposes. So whereas I will always try to help out a FFIV hacker who asks me, the ideal situation here is to redirect him to good resources without actually having to spend the time learning this myself.
 :blush:

562
Final Fantasy IV Research & Development / Japanese Title Screen
« on: March 08, 2015, 01:13:12 AM »
Does anybody know anything about the Japanese title screen?

Somebody over on RHDN just asked me about it... I don't really know anything about title screens, but I also haven't really looked into them (JCE3000GT created my custom title screen).

Specifically, he was asking if I knew anything about the animation. To be honest, I don't recall fully what's going on in the Japanese title screen, but I think it's a flashing crystal, which I presume is executed using a rotating palette. Shouldn't be that hard to figure out, but I figured I'd put it out here first to see if anyone has any insight into the matter.

Cheers!

563
My Protect/Shell Status Mod also uses one unused stat byte. (x74) since I never saw any part of it being used.

We don't often use those unused bytes in our routines as we don't often need to. They do make good spaces for new status spots though.
Aha. I stand corrected. :)

564
That's a good point - all of those battle-only things could be easily relocated, and could use the same indexing as the normal battle stat locations (separated by 80 bytes per character).

Grimoire and I have certainly talked about using unused stat bytes a bunch before, but to my knowledge, only User Options (for the ATB percentage) and my long-term project (for the limit breaks) actually do it.

565
There's a huge block... I wanna say 7E4800-7E7000 (that's far from exact) that as far as I know is completely unused. But I haven't watched it through the whole game, so I cannot confirm.

I'm not aware of any FFIV hacking projects before my own that actually make use of unused stat bytes (but I don't have the "historian" cred that, say, Grimoire has, so I could be mistaken). It should be noted that those bytes only exist during battle. The out of battle character record is only 0x40 bytes long and all are used.

566
I was just going to suggest an ATB bar too!  Would this use the 2nd control timer .. what I call the "master control timer"?  That value technically decreases to zero over time starting from a varying value; how would you calculate an increasing percentage from it?

Are you talking about the timers at 7E2A07?
If so, then yes.
The current version of my User Options patch makes use of some normally unused character stat byte... like 2043,x or something.
When the timer resets (is at its highest point), the value is stored into that character stat byte
then it keeps checking the timer and uses this formula (where M is the max timer value and C is the current timer value):
(M-C)/M
The result is a 16 bit value (without looking at it again... I don't remember exactly how the calculations work) that then goes through the normal decimal conversion routine to be displayed as a percentage in the Party HP window.

Now those are some brilliant ideas! 

One thing that may need to be tweaked is the HP per level for the characters so after say level 69 when the lovely 70-99 level ups happen the melee characters have the ability to go over 9999 at some point.  Or would you add another Apple item that raises more than 50/100 HP?  If it were me I would raise the EXP requirement for levels 50-69 to be about double the default amount, but, as a reward for leveling up get a substantially larger amount of HP per level up. If memory serves me I believe the only character than could legitimately get over 9999 is Yang without the use of Silver/Golden Apples.  Cecil statistically can get close (~9800?) if you manage to roll the lucky number every time. 

What do you all think?

If you're increasing HP and damage all around and making the higher values generally available, then I don't think you need to make it harder to get to the levels that will exceed 9999 HP.
I mean, anybody who gets their characters up to Lv. 99 in FFIV is doing a lot of grinding anyway...

If you want to make above 9999 values "special," like they are in FFX, then I wouldn't build them naturally into the level-up system.
Apples would be one possibility...
Then there's the possibility of creating equipment that increases the wearer's max HP by a percentage (though I don't know exactly how this would work... FFIV doesn't seem to have a place to store base vs. adjusted Max HP like later FF games)
You could also make equipment that gives HP bonuses at level up (make the level up routine say, "check for bonus armor, if equipped, add 200 to the level up HP award")

Or... what about simply increasing the max level? Again, I don't know exactly how difficult this would be without doing some research... the sticking point in my estimation would be whether the "current Exp" and "Exp needed for next level" have enough room for many more levels.
But if characters could level up to, say 150, then Cecil and Kain would have no problem exceeding 9999 HP eventually.

567
OK, I had a thought about the feasibility of the five-digit party HP display. It's related to something that's been on my mind for a while.

Whereas there wouldn't be enough room in the battle window to display [current HP]/[max HP], there is enough room to display [current HP][space][something three characters wide].
Meaning you could do [current HP][space][percentage of full HP].
I could also rework User Options to accommodate the change, so the percentage would display %max HP or %ready depending on the selected option.

... Now here's where the brainstorm really gets good... Instead of [current HP][space][three space wide percentage], we could do [current HP][four space wide meter].
Using the wealth of empty space for numbers and letters leftover from the Japanese editions, we could make 8 new "letters" - a single, right-aligned vertical line (one pixel wide), two pixels wide... All the way up to an 8-pixel full box. Stack four of those side by side, then create an algorithm that tells the game:
1) calculate the appropriate percentage (either Max HP or Readiness). you'd only need a one-byte value, but two bytes would yield more accuracy, of course. User Options is already doing this for readiness.
2) If the percentage is FF (100%, FFFF if using two bytes), then display [full box][full box][full box][full box]
3) for every 0x06 the percentage decreases (or 0x0666 for two bytes), decrease the meter, so if the percentage (one byte) is F9, then display [7-box][full box][full box][full box]

There's probably a more numerically efficient way to make those meter bars decrease (similar to how the game displays numbers, I'd imagine), but this would certainly work.

I'm not sure I could fully get behind a five digit HP value without a way to display max HP, and this could be the answer.

568
Well, that certainly would solve the whole issue of expanding HP to 24 bits... It would also help explain why Meteo kills Tellah.
Sure, yeah, I think something like that has potential!

So mages, then, would have a max HP closer to fighters, but it drains more quickly the more spells they cast. I think it adds an interesting dimension to gameplay, actually...

569
While I'd love to see it happen, how feasible it it really?

Near as I can figure, monster HP can't be expanded to 24 bits unless party HP is as well, since damage routines are the same for both. There's plenty of unused bytes in monster stat records, but not so many in party stat records. Then there's rewriting all of the monster data in ROM (ugh).
It just seems like such a massive undertaking.

I mean, don't let me discourage you if it's something you want to tackle... I'll help if I can, but the thought of trying to make it all work makes my head spin a little bit.

570
I plan to list avalanche and JCE3000GT as hackers on this project, as well as myself.

Very kind of you, though I don't think I really helped any.
Nonsense. Having a person off of whom to bounce ideas is extraordinarily important, IMHO (which is why Grimoire LD makes it into the credits of almost all of my ROM Hacking endeavors). And I'm sure some of the things you posted here helped me focus what I was doing.

Quote
The need for some unused space for assembly got me thinking.  Is there a tool that can detect whether a set of patches conflict with each other?  Detecting logical problems would not be doable, but it should be possible to check if they modify the same existing code or reuse the same unused space.  I suppose it would just be detecting an overlap in the range of bytes an IPS modifies.
I would use a tool like that all the time. So many of my mods end up being incompatible with each other. I have a bad habit of using the same "free" space over and over again.