øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=339;area=showposts;start=30e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexd53e-2.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=339e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexd53e-2.html.zxÛ›h^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ00W ¬OKtext/htmlISO-8859-1gzip@øÕ ¬ÿÿÿÿÿÿÿÿWed, 11 Mar 2020 08:22:11 GMT0ó°° ®0®P®€§²ð®Ú›h^ÿÿÿÿÿÿÿÿ' ¬ Show Posts - avalanche

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 - avalanche

Pages: « 1 2 3 4 5 6 7 8 9 »
31
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 01, 2015, 07:11:31 PM »
Arg.  I tried to use the MVN instruction combined with finding a few places in ROM that happened to have the needed bytes for the "Miss!" sprites (6C 6D 6E 6F).  But that instruction takes SO many other instructions to setup, plus I found that it has the side effect of changing the data bank register, so that has to be restored or the game hangs, and by the time all that is added, it was still 1 byte too long.

By the way, if you ever go to use the MVN or MVP instructions, the description at http://wiki.superfamicom.org/snes/show/65816+Reference is completely wrong.  It appears reasonable, but don't trust a single word of it...  This PDF is a much more thorough and accurate document, but much less handy:  http://wiki.superfamicom.org/snes/files/assembly-programming-manual-for-w65c816.pdf

32
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 01, 2015, 02:59:39 PM »
I think the bounce looks okay, perhaps the screenshot was taken at an awkward moment.

If your results are working, then that's good.  I'd be concerned about introduced bugs by changing the decimal conversion routine as you did, because there are perhaps 4 callers in the bank, but I could only discern what two of them were (party HP window and damage), and that greater-than-9 first digit -- and maybe semantically different other digits -- could in theory cause problems with the other callers.  The fact that the original decimal conversion routine already did 5 digits makes me want to use it unmodified, but what you did could certainly be an ingenuitive hack to only write 4 (albeit special) digits, so long as no other caller got tripped up by it.

I fixed the "06" problem by making a few more 1-byte tweaks, but at least the "Miss!0" remains to be fixed.  For my hack attempt, I am actually using all 5 digits (oddly yours is not...), so I think I actually need an FF written into the 5th byte to blank out any remnant digit.  Like you, I wanted to avoid jumping to an unused section for additional assembly due to the conflict with other patches, but I was not able so far to fit a code change in place that sets the Miss sprites to also put a proper FF in there. 


I forgot to touch on the ROL vs ASL topic before.  ROL indeed works similarly to ASL, but where as ASL always puts a 0 for the new bottom bit and the top bit is discarded, ROL moves the carry flag into the bottom bit and then puts the top bit into the carry flag.  That way the carry flag can be used as temporary memory, and that is why it is often combined into a 2-byte operation.  i.e. during the first use, the top bit moves into the carry flag, and during the second use, the carry flag moves into the bottom bit.  You can see how this mimics a single 16-bit operation.  You'll also see that all uses of ROL or ROR probably have a SEC or CLC beforehand to ensure they know what the value of the carry flag is upon the first use.

33
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: March 01, 2015, 10:40:28 AM »
Well, I still think the division and decimal conversion routines are okay.  The decimal conversion writes 5 digits to $180C,180D,180E,180F and 1810.  180B is not related.  I also don't think DBE5 is part of it, so I suppose that could result in reading a bogus value.

The reason that the 10K digit is missing is because they discard it.  Excerpt:
Code: [Select]
02:CA08  20 BF 86    JSR $86BF                 decimal conversion routine
02:CA0B  20 16 87    JSR $8716                 discard first digit, blank out leading zeros, set X to first digit to display
First it calls the decimal conversion, so 180C-1810 have all 5 correct digits.  But the next routine called shifts all the digits over, discarding the 10K digit, then does some other things like writing an FF over leading zeros (so they don't show), and leaves X pointing to the index of the first digit to show.

That second routine is the problem, and it called in multiple places, so we may not be able to totally change it without breaking other things. 

Here's what I tried, just two bytes changed so far: 
Code: [Select]
FROM  02:CA0B  20 16 87    JSR $8716
TO    02:CA0B  20 25 87    JSR $8725

FROM  02:CA3A  E0 04 00    CPX #$0004
TO    02:CA3A  E0 05 00    CPX #$0005
The first change skips over the digit-discarding part but performs the rest of that subroutine.  And the second causes it to copy 5 digits to the DBE7 area.  You're right and it's cool that the game otherwise allowed for 5 digits.  Attached is an example running with those changes.

Unfortunately, there is one part not perfect about this.  Above I mentioned that the routine leaves X pointing to the first index to show. Well with this hack, if you do a single digit worth of damage it will have a leading zero like "06".  If we change it to fix that, then some of the callers of that routine will get messed up because they assume it discards the leading digit.  I would hope that's fixable by tweaking the various callers, but I have not tried that yet.  Hehe it also says "Miss!0" or similar the next time because they don't clear everything properly.

34
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: February 28, 2015, 09:51:12 PM »
Cool, glad you got it!

Can I ask where it was that you modified, or where it had the larger-than-9 digit?  I'm pretty sure that 02:852B (division) and 02:86BF (generic binary-to-decimal conversion) are okay.  The latter should put 5 good digits into $180C-$1810.  Code at 02:8716, however, discards the first digit dropping it to 4.  But I'm not sure where the code is that calls the decimal conversion and ultimately finds its way to the sprite setup. 

35
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: February 28, 2015, 12:16:51 PM »
Yes, priority is like the Z index, and is the order of sprites but also between sprites and bg layers too. It's nontrivial though when comparing bg's and sprites.

Character is what the SNES docs call it. It is the index into the sprite graphics loaded elsewhere in video memory. Sprite index makes better sense to me though.

As for your latest post, I came across some relevant 4-assuming code where it takes the 5, then ignores the first, before it gets to the sprite code you found. I am not home to post exactly where right now though. But I should be able to do that tonight or tomorrow if you are still on the problem.  But the low level decimal conversion itself keeps all 5 for sure. It's somewhere else that discards it.

36
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: February 27, 2015, 03:45:46 PM »
Excellent, those 4-byte records are the hardware sprite format.  FYI the 4th byte format is
Code: [Select]
vhoopppc
  v: vertical flip
  h: horizontal flip
  oo: priority
  ppp: palette
  c: 9th bit of sprite index (aka character)

Another thing is that there are only so many sprites available for the digits, but I don't know how many that is.  Is the most that can be displayed at once 8 monsters * 5 digits, or are there some spells that need all 13 actors * 5?


37
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: February 27, 2015, 11:35:18 AM »
Yep.  As you mentioned earlier, 16383 is going to be the largest number valid in many parts of code because of the flag bits.  So if you forced damage numbers like 54321 pretty late in the pipeline, it might work okay, but earlier parts might misbehave because of those flags.  I'm sure it wouldn't be the only problem though, so this is a minor thing.

The 321K damage is pretty rad though   : )

38
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: February 27, 2015, 09:28:16 AM »
That looks to be the case.  Are values above 14 bits valid in the place you inserted those damages?

39
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: February 27, 2015, 09:09:55 AM »
Ah, the ROLler you are talking about is 02:852B which oddly enough is the same division routine I mentioned from bank 3, but for some reason coded slightly differently.  In any case, it divides and produces an integer division in $2A and remainder/modulo in $2C.  The former is used as the next digit, while the latter is used for calculating the next digit on the way down.  Interestingly that does indeed work for 5 digits.

I would bet that the routine at 02:86BF is probably used for any decimal conversion for display, at least in battle, including the party battle window HPs, and perhaps the monster HP in a Peep result, which actually needs 5 digits.

I tried setting the damage to 12345 and while this routine did calculate 5 digits properly, only 2345 displayed in bouncy numbers, thus whatever 3 changed bytes you mentioned must be needed to setup the bouncy sprites.  You're already past this part, but I was curious how they performed the decimal conversion, so I popped in to take a look.

40
Final Fantasy IV Research & Development / Re: Chillyfeez's Mods, hacks, research notes, etc.
« on: February 26, 2015, 05:42:47 PM »
Quote from: chillyfeez on February 26, 2015, 03:08:32 PM
the first thing I noticed was one of those routines that stores the value into RAM and does a whole lot of ROL-ing... So I have that kind of headache to look forward to  :childish:

Are they bank 3 routines?  I have some thoughts what a few of those do in that bank.  For example, one that uses ROLs, 03:8407 I think is a 16-bit division, which produces a 16-bit integer division result and possibly a modulo or remainder.

41
Final Fantasy IV Research & Development / Re: Some palette tricks (Lava glow, Trippy Tower of Babil, Big Whale)
« on: February 13, 2015, 01:30:07 PM »
Quote from: Grimoire LD on February 11, 2015, 05:17:51 PM
Rather neat to know regardless, especially for the case you mentioned of not having the second Overworld map being so lava-y. Though the Laval Pulsating glow is also used in Sylph's Cave isn't it? Though that's green. Or is that a different set up?

Similar effect, but not applied in the same routine. See the link in the first post for the sylph glow and others.

42
Final Fantasy IV Research & Development / Some palette tricks (Lava glow, Trippy Tower of Babil, Big Whale)
« on: February 09, 2015, 03:25:38 PM »
Here are a few more palette tricks used by the game, in addition to those posted in the FF4kster thread a while back.  (http://slickproductions.org/forum/index.php?topic=1713.msg22009#msg22009)

15:C4D3 - Lava pulsating glow.
When in the underground, palette 1 (0-based) is overwritten every frame, pulled from one of 4 consecutive palettes stored at 14:FA16 (ROM A7C16).  The pulse pattern which says which of the 4 to use at any moment is defined by an 8-byte entry at 15:C503 (ROM AC703).

15:C3C3 - Big Whale running lights in flight.
When flying in the whale, just one color of the palette used by the whale is overwritten, pulled in sequence from an 8-color table at 15:C3E0 (ROM AC5E0).

15:C3F0 - Psychedelic trippy Tower of Babil colors.
When event flag 66 is set (after Kain steals the crystal), and when in either the Overworld or Underground, the frame counter byte itself is used to make a funky color entry and written to the palette used by the Tower tiles.  Oddly the tower tiles use a different palette index for the two different worlds, but the effect is the same.  Black is used instead when the flag isn't set.


I can't imagine these would be very useful to anyone.  But if anybody wanted to say, turn the Underground into something that wasn't so yellow and lava-ish, there ya go!  Of course, these kinds of routines could certainly be modified or mimicked to add pulsing or other effects to different maps entirely.

43
Final Fantasy IV Research & Development / Re: Avalanche's Project: FF2
« on: February 08, 2015, 10:05:42 PM »
Thanks all for the feedback!

LordGaramonde: it doesn't have to be two different banks, either. There are *lots* of memory copies in the code that could be made with that instruction, but are manual loops instead. I think there are quite a number of useful instructions they just don't happen to use in the original code, and I'm not sure why.

Chillyfeez: it's a ton of javascript, really. Not an emulator; it doesn't run a ROM for example.  But is like any other web game. You go to the site, and you see the familiar title screen, and can play from there. I've worked on games before, and remaking old ones is just so much fun. But this is by far the most complete. Probably because this one is such a favorite from childhood.

Grimoire: definitely trying to avoid some of those limits like a fixed number of NPCs, sprites, all that stuff. I originally wanted it to be moddable. I still want that, but getting the original working is my priority for now, and it sure is a lot of work.  But one of the cool things about what you do is that you could technically burn a cartridge and play your game on a real console

44
Final Fantasy IV Research & Development / Avalanche's Project: FF2
« on: February 08, 2015, 08:15:28 PM »
I thought I'd take a moment to post something about the project that I've been working on.  My goal when deciphering disassembly and cracking how spell visuals work, etc, has been from a slightly different point of view than many of you, who modify the game to make it do something different than the original.  What I have been doing is deciphering how the game works and getting as much data as I can from it, so that I may remake the game from scratch, as exact as possible.  My goal is to be pixel-perfect... every screen transition, the way a character walks forward to attack, and so on.  Though there have been a couple of places where I had to make some concessions or chose not to reproduce a bug that was in the original.  I'm sure I'll have enough quirky bugs of my own! : )

It is a combination of cracking how the original assembly does something, trying to decipher whether and how data is stored in the ROM and finding a way to use it, and original programming.  It's interesting to me how there is a large amount of information that is useful both to me and to those of you hacking the original game, and that there are also a few things that I need to know that you don't, or vice versa.  For example, figuring out how the game did the spell visual effects was crucial for my project, but might not quite be as interesting to other FF4 hackers.

I attached a few random screenshots.  As you can see, the platform is a browser.  I won't ever release it for general use, for obvious reasons, but it would be really great to show to some people eventually.  It's complete and fully playable nearly to the underground as of right now.

45
Final Fantasy IV Research & Development / Re: Damage + Sap = Can't absorb??
« on: February 08, 2015, 03:22:04 PM »
I'm not familiar with that one (or any, for that matter) but I was referring to an assembler that would compile the assembly to the binary that could be patched.  There would be some advantages for *some* use cases. For example, branch and jump targets could be labels/names instead of hardcoded addresses, so if you remove a line or two, all the branches and jumps in the whole area don't have to be adjusted by hand.

I will say that for most of what we do here, it would likely be the opposite of helpful.  But when picturing recoding all of the spells and consolidating the new free space, it could be nice. Hard to say.

Pages: « 1 2 3 4 5 6 7 8 9 »