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

571
Meteo ends up being significantly more powerful than bahamut. The difference is more noticeable the larger the enemy party. Test around the group of eight imps/imp caps that can be found around Fabul to see.

572
The patch is up on RHDN.
http://www.romhacking.net/hacks/2343/
(as of 3/4, credits are pending, because the site doesn't let you add credits until the main submission has been approved)

573
No. There are several reasons why I wouldn't do that, the biggest one being the lack of space in the party HP window. After the brief (and ultimately failed) foray I took into trying to expand command and/or spell names, the one thing I know for sure is that what is going on in those windows is really complicated. Even if I was able to properly resize the battle windows to accommodate two extra characters, I'm not sure I'd be able to make an extra digit display there, or if the work it'd take would be worth the reward.

I dunno, maybe I'll look into it someday, but it's not high on the list of priorities.

574
Well, it works!
Props to JCE3000GT for finding and posting the location of the damage limits... I was having a bit of trouble finding them on my own.

As for other calls to the decimal conversion routine that I've butchered... The game is constantly calling the routine during battle, which leads me to believe it is used for the party HP window (which is constantly updated), but that won't matter because party members' HP never rate higher than 9999. I tried casting the Peep spell and using the Peep ability on monsters with 65535 HP and it displayed just fine, so I'm operating under the belief that there is no collateral damage from what I did.

Don't get me wrong, I still like the idea of being able to do this without any custom-written assembly, but I'm satisfied with these results.

These images show actual damage outputs (of course, with lv. 99 characters and maxed out stats)





And Kain's Jump attack:



I do intend to put a patch together to submit to RHDN. There's quite a bit of FFIV hacking going on there at the moment, and I think some of those folks might be interested in this.
I plan to list avalanche and JCE3000GT as hackers on this project, as well as myself.

575
That 5 in the ones place also looks like it's bouncing a bit oddly.
From what it looks like, you're drawing your digits from DBE7-DBEB.
If you use DBE6-DBEA instead, I think it will follow the wave pattern of the upper four digits more closely.
It it possible that might also solve the "miss!0" issue, since "miss!" is loaded into DBE7-DBEA?
... On second thought, it might not affect the bounce at all, but it should fix "miss!0"

So far, I still prefer the result of my method, but you may be on to something here.

576
OK, let me try to explain everything I've done so far...

So, the place in RAM where the digits are stored immediately before they're loaded for visual processing is 00:0340. As previously mentioned, it's four bytes per digit: x,y,(digit+70),(vhoopppc).
It should be noted that the game does, by default, assign five digits per target, even though five digits are normally never used.

Now, byte 2 of those entries (the digit) is loaded into the table at 0340 from a table at 7E:DBE6. This table also assigns five digits per target, but the uppermost digit is never loaded into 340. Instead, the game loads 1000s, 100s, 10s, 1s and the 10000s of the next entry (which is always FF, or blank) into the entry for each target.

So, the first fix was to change
Code: [Select]
$02/E5AA BD E6 DB    LDA $DBE6,x[$7E:DC19]which is the opcode responsible for loading each displayed digit, so that it reads
Code: [Select]
$02/E5AA BD E5 DB    LDA $DBE5,x[$7E:DC18]
So now the game is accounting for the correct five digits for each target. As a result, the damage digits display one sprite to the right from where they normally would, but I personally find that completely inoffensive. It can probably be shifted, but I say why bother? It looks fine.

So now we're at the point where the problem at hand is the fact that nothing is being loaded into the 10000s place digit. You can cheat the damage up to 16383, but only "6383" will show up. This has to do with the decimal conversion process, and more specifically what the game is doing (or not doing) with the last remainder.

The conversion routine loads the digits into 180C-180F, and they are loaded from there into the table at DBE6. As far as I can see, the 10000s place digit is never loaded into 180B.
So I spent a while watching a live disassembly of the conversion routine. I still don't get what is happening or how it happens. My understanding of the ROL opcode is that it essentially works like ASL, except that it can be performed on two bytes at once... and sometimes if you ROL 00 00, you get 01 00, and I have no idea where that bit comes from.
anyway... from what I can see, the storing of digits into 180C-180F is pretty hardcoded. the game doesn't do a STA $180C,x op that is performed four times as X increases. it's STA $180C, STA $180D, STA $180E and STA $180F. What I did notice was, right before the jump into this subroutine, the game does this:
Code: [Select]
$02/86C1 A2 10 27    LDX #$2710
Well, 0x270F is equal to 9999, so it occurred to me that this op might be setting the upper limit of what numbers are considered in the decimal conversion process.
So since we want the game to accept damage as high as 0x3FFF, I changed this op to:
Code: [Select]
$02/86C1 A2 00 40    LDX #$4000
I then cheated 0x3000 damage into A4 and watched what happened...
0x3000 is equal to 12288.
The output I got on screen was "[random incorrect sprite]288"
So I looked at what was in the table at DBE6...
Bear in mind that the format for digits is (actual digit + 70), so correct would be 71 72 72 78 78
What I had was FF 7C 72 78 78
Well, A + 2 = C, which means what the game was doing was now accounting for the value over 9999, but instead of separating that 7C into two usable digits, it was just going with it.
So I found the op that stores 7C into DBE7:
Code: [Select]
$02/CA35 99 E7 DB    STA $DBE7,y[$7E:DBED]
$02/CA38 C8          INY                  ;(I needed this one-byte op to, because I was writing a JSL)

And I changed it to:
Code: [Select]
$02/CA35 22 E0 EF 12 JSL $12EFE0[$12:EFE0]
Then wrote the subroutine:
Code: [Select]
$12/EFE0 C9 7A       CMP #$7A             ;compare the digit about to be stored into the table with 7A
$12/EFE2 90 0A       BCC $0A    [$EFEE]   ;if it is lower than 7A, skip to the end of this routine (and proceed as normal)
$12/EFE4 48          PHA                  ;if it is 7A or higher (which will only happen with the digit in the 1000s place, then stack it
$12/EFE5 A9 71       LDA #$71             
$12/EFE7 99 E6 DB    STA $DBE6,y[$7E:DBED];load 71 into the 10000s place
$12/EFEA 68          PLA                  ;pull the digit back off the stack
$12/EFEB 38          SEC                 
$12/EFEC E9 0A       SBC #$0A             ;subtract 0A
$12/EFEE 99 E7 DB    STA $DBE7,y[$7E:DBEE];then proceed as normal
$12/EFF1 C8          INY                  ;(this is a replacement of that INY we cannibalized at 02/CA38
$12/EFF2 6B          RTL                 

And there you have it!
Five digits now display properly... as long as you cheat in damage over 9999. I still haven't gotten to the point of turning off those limits. For the most part, this will just be a matter of finding them (there are several, different ones for damage routines of different commands) and changing them from 270F to 3FFF.
The Multi-Target damage routines may require a little figuring out, because I think the game does something weird where if the total calculated damage is over 9999, the first target gets 9999 and the rest of the damage is distributed among the remaining targets... or something like that.
Oh well, we'll see.

I'm off work today, but I have some chores to do, so I'm not positive I'll be able to get a lot of work in on this.
Here's hoping.

577
Yeah, I've been keeping notes on a notepad file as I go, and was intending on posting it all once I had the patch up and running, but I can put up what I've got so far... Except I'm already in bed for the night, so I will do tomorrow morning when I get up.

578
I actually got it working, but it did require a bit of custom code, since I still don't fully grasp how the conversion is working. I can alter that routine so that it acknowledges values above 9999, but it still stores one digit above 9 in the 1000s place, so to work around this I wrote a 0x13 byte routine that basically says:
If [digit] is >9, then store 1 in the next digit up, subtract 10 from [digit] and store.
I was hoping I could do it all without any custom code (which still might be possible), but this works flawlessly, so I am satisfied with it.
If you want to look into making that routine account for the 5th digit, though, I would still be interested in seeing that happen.

The only step left is to "turn off" the 9999 damage limit(s) and this will be a working hack!

579
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.

Hmm, even though I've activated display of the 10000ths place digit, it's still not showing up in bouncy numbers, so the routine at 2852B must be throwing out the remainder after four digits instead of storing it in the place that was already set aside for a 5th digit. Silly.
So I'll have to zero in on the place where that digit exists and tell the code to use it instead of disposing of it...

580
Ha-ha! brilliant!

Turns out I was doing too much. I didn't need to change three bytes. I only need to change one byte!



I'm getting very close to making this thing a reality!

581
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)
"Priority" means, essentially, layer, I presume... Whether it appears over or under existing sprites?
And what's character?

Quote
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?
AFAIK, 8*5 would be the most. Ffiv doesn't have a merton-style spell that hits all monsters and all party members.
The area of RAM the sprites are loaded from certainly has enough space to accommodate 40 digits, so here's hoping that won't be a problem for the hardware to display...

582
Oh, I see what you're saying.
No, it's entirely about how things are being counted per monster.
See, the 20 digits that are being displayed here are set up all in a row. Each one has four values - x-pos, y-pos (which changes several times for the bouncy effect), actual displayed digit pointer (equal to the digit's value plus 70), and "31" (I have no idea what this one does). The reason things aren't displaying properly has everything to do with the fact that it's only assuming four digits per monster when it assigns the x and y positions to each digit.

583
Sorry, which places I inserted those damages?
Are you referring to the problems related to the picture I posted?

584
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.

Well that's good to know... so assuming I can get the bouncy number display routine to properly  display for multiple monsters - and of course re-set the damage limits - the decimal conversion shouldn't be an issue?

585
Hmm... it seems I've missed something.
five-digit display works fine for one monster, but for multiple monsters (and presumably party members) I get results like this:


The damage readouts should say "12345," "67890," "54321" and, "98760."
Only the first one shows up correctly (the top imp, with 12345). Looking at the data just before it's loaded for visual processing, I can see (inasmuch as I understand everything) that, for certain pieces of data, it's still assuming that it's counting four digits per target. So hopefully it's just a matter of finding those instances of multiplication and changing them to five instead... which will in fact require some extra code, since x4 is only two bytes (ASL A, ASL A) and x5 is at least seven bytes (STA [dp##], ASL A, ASL A, CLC, ADC [dp##]).
 :bah:

Oh well, I'll get there eventually, it's just gonna take some time...