øA slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&topic=2374.0;wap2 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index0f0d-2.html slickproductions.org /forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&board=17.0;wap2 e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index0f0d-2.html.z x ôg^ ÿÿÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ °,0 õE OK text/html ISO-8859-1 gzip 8:Ö õE ÿÿÿÿÿÿÿÿ Tue, 10 Mar 2020 20:26:10 GMT 0ó° °® 0® P® €§² ð® ôg^ k õE
Library of the Ancients > Final Fantasy V Research & Development
Enemy Group size/spell animation issues
Praetarius5018:
So theoretically the game can have 8 enemies in battle at the same time.
This doesn't seem to be a good idea.
If there are 7-8 enemies alive at the same time, casting a multitarget spell will crash the game.
"Simple" animations like Bolt survive 7 enemies (at least in my test group) but 8 was too much.
Fire3 glitches the game at 7 enemies already. I had to restart the entire emulator, loading savestate didn't suffice for some reason.
Ice2 doesn't crash the game at 6 enemies, but the 6th enemy didn't display the "got hit" part of the animation.
Ice1 passed even 8 enemies but was very laggy.
The biggest "natural" enemy group I know of has 6 of those Puroboros bomb enemies and a quick search found no enemy formation that even used the 8th slot.
Also anything targetting the 8th enemy exclusively somehow lands instead on the parties first character. But only while all 8 are alive.
This is confusing, yo...
Background is:
I wanted to use the unused enemy slots for random encounters and make it really random.
Enemy slot 1-8 would all be filled and then RNG decides at battle start that enemy 2,4 and 7 stay home.
So far the theory. Reality... has crashed and needs a reboot.
So what I wanted to know is, has anyone ever used those "extra" monster formation slots successfully or just stuck to vanilla?
Squall:
--- Quote ---The biggest "natural" enemy group I know of has 6 of those Puroboros bomb enemies and a quick search found no enemy formation that even used the 8th slot.
--- End quote ---
Correct. No 8 slot battle. There are couple of 6 slot - 209, 270, 467. There are couple of 7th slot battles, but we will never see all 7 on screen at the same time - 101, 447, 495, 501; GBA only - 629, 597
I was always wonder, why they dont use all 8 slots. Maybe they have experienced similar crashes and made 'soft' lock up to 6. Your idea of having random is interesting. FF1 & 2 heavily rely on random numbers, while FF5 is strictly predetermined.
P.S. I wonder what cause the crashes ... is it software bug, is it some 'hidden' limitation of the GPU. Will the game crash if we use contemporary powerful PC? What about a different emulator?
Praetarius5018:
FF1adv is probably the final fantasy I'm most familar with. At least the one I completed more than once (or never for most games in the series)
I'm honestly not even sure if I ever finished FF5, hmmm.....
I guess 8 targets was never intended.
Kinda funny how in the NES games you can have spells hit 9 targets no problem and the FF5 code gives up at 7.
I was 99% sure it is just the GPU at its limit; the whole screen turns to garbage and music continues.
The more "parts" an animation has the less targets it can endure.
And counterpoint...
at least in case of Fire2 it looks like a unintended JMP target
--- Code: ---$C1/1186 AD 3A CD LDA $CD3A [$7E:CD3A] A:0004 X:0000 Y:0040 P:envMxdIzc
$C1/1189 0A ASL A A:00F0 X:0000 Y:0040 P:eNvMxdIzc
$C1/118A AA TAX A:00E0 X:0000 Y:0040 P:eNvMxdIzC
$C1/118B BF 9B 11 C1 LDA $C1119B,x[$C1:127B] A:00E0 X:00E0 Y:0040 P:envMxdIzC
$C1/118F 85 88 STA $88 [$00:0088] A:009D X:00E0 Y:0040 P:eNvMxdIzC
$C1/1191 BF 9C 11 C1 LDA $C1119C,x[$C1:127C] A:009D X:00E0 Y:0040 P:eNvMxdIzC
$C1/1195 85 89 STA $89 [$00:0089] A:00BC X:00E0 Y:0040 P:eNvMxdIzC
$C1/1197 6C 88 00 JMP ($0088)[$C1:BC9D] A:00BC X:00E0 Y:0040 P:eNvMxdIzC
$C1/BC9D 86 F5 STX $F5 [$00:00F5] A:00BC X:00E0 Y:0040 P:eNvMxdIzC
$C1/BC9F 1A INC A A:00BC X:00E0 Y:0040 P:eNvMxdIzC
$C1/BCA0 0A ASL A A:00BD X:00E0 Y:0040 P:eNvMxdIzC
$C1/BCA1 AA TAX A:007A X:00E0 Y:0040 P:envMxdIzC
$C1/BCA2 7B TDC A:007A X:007A Y:0040 P:envMxdIzC
$C1/BCA3 A8 TAY A:0000 X:007A Y:0040 P:envMxdIZC
$C1/BCA4 BF 42 7D D9 LDA $D97D42,x[$D9:7DBC] A:0000 X:007A Y:0000 P:envMxdIZC
$C1/BCA8 99 1A D4 STA $D41A,y[$7E:D41A] A:0094 X:007A Y:0000 P:eNvMxdIzC
$C1/BCAB 98 TYA A:0094 X:007A Y:0000 P:eNvMxdIzC
$C1/BCAC 18 CLC A:0000 X:007A Y:0000 P:envMxdIZC
$C1/BCAD 69 10 ADC #$10 A:0000 X:007A Y:0000 P:envMxdIZc
$C1/BCAF 00 A8 BRK #$A8 A:0010 X:007A Y:0000 P:envMxdIzc
--- End code ---
all iterations before always had a 0 in 7E:CD3A
--- Code: ---$C1/118B BF 9B 11 C1 LDA $C1119B,x[$C1:119B] A:0000 X:0000 Y:0880 P:envMxdIZc
$C1/118F 85 88 STA $88 [$00:0088] A:009A X:0000 Y:0880 P:eNvMxdIzc
$C1/1191 BF 9C 11 C1 LDA $C1119C,x[$C1:119C] A:009A X:0000 Y:0880 P:eNvMxdIzc
$C1/1195 85 89 STA $89 [$00:0089] A:0011 X:0000 Y:0880 P:envMxdIzc
$C1/1197 6C 88 00 JMP ($0088)[$C1:119A] A:0011 X:0000 Y:0880 P:envMxdIzc
$C1/119A 60 RTS A:0011 X:0000 Y:0880 P:envMxdIzc
--- End code ---
we can guess where this loop is going, right?
--- Code: ---$C1/6505 7A PLY A:0050 X:0100 Y:0010 P:envMxdIZC
$C1/6506 98 TYA A:0050 X:0100 Y:0000 P:envMxdIZC
$C1/6507 38 SEC A:0000 X:0100 Y:0000 P:envMxdIZC
$C1/6508 E9 10 SBC #$10 A:0000 X:0100 Y:0000 P:envMxdIZC
$C1/650A A8 TAY A:00F0 X:0100 Y:0000 P:eNvMxdIzc
$C1/650B C9 F0 CMP #$F0 A:00F0 X:0100 Y:00F0 P:envMxdIzc
$C1/650D D0 ED BNE $ED [$64FC] A:00F0 X:0100 Y:00F0 P:envMxdIZC
$C1/650F A5 92 LDA $92 [$00:0092] A:00F0 X:0100 Y:00F0 P:envMxdIZC
$C1/6511 8D 3A DB STA $DB3A [$7E:DB3A] A:0040 X:0100 Y:00F0 P:envMxdIzC
$C1/6514 C2 20 REP #$20 A:0040 X:0100 Y:00F0 P:envMxdIzC
$C1/6516 0A ASL A A:0040 X:0100 Y:00F0 P:envmxdIzC
$C1/6517 0A ASL A A:0080 X:0100 Y:00F0 P:envmxdIzc
$C1/6518 AA TAX A:0100 X:0100 Y:00F0 P:envmxdIzc
$C1/6519 7B TDC A:0100 X:0100 Y:00F0 P:envmxdIzc
$C1/651A E2 20 SEP #$20 A:0000 X:0100 Y:00F0 P:envmxdIZc
$C1/651C A9 F0 LDA #$F0 A:0000 X:0100 Y:00F0 P:envMxdIZc
$C1/651E 9D 0A 7D STA $7D0A,x[$7E:7E0A] A:00F0 X:0100 Y:00F0 P:eNvMxdIzc
$C1/6521 E8 INX A:00F0 X:0100 Y:00F0 P:eNvMxdIzc
$C1/6522 E8 INX A:00F0 X:0101 Y:00F0 P:envMxdIzc
$C1/6523 E8 INX A:00F0 X:0102 Y:00F0 P:envMxdIzc
$C1/6524 E8 INX A:00F0 X:0103 Y:00F0 P:envMxdIzc
$C1/6525 E0 00 01 CPX #$0100 A:00F0 X:0104 Y:00F0 P:envMxdIzc
$C1/6528 D0 F4 BNE $F4 [$651E] A:00F0 X:0104 Y:00F0 P:envMxdIzC
$C1/651E 9D 0A 7D STA $7D0A,x[$7E:7E0E] A:00F0 X:0104 Y:00F0 P:envMxdIzC
$C1/6521 E8 INX A:00F0 X:0104 Y:00F0 P:envMxdIzC
$C1/6522 E8 INX A:00F0 X:0105 Y:00F0 P:envMxdIzC
$C1/6523 E8 INX A:00F0 X:0106 Y:00F0 P:envMxdIzC
$C1/6524 E8 INX A:00F0 X:0107 Y:00F0 P:envMxdIzC
$C1/6525 E0 00 01 CPX #$0100 A:00F0 X:0108 Y:00F0 P:envMxdIzC
$C1/6528 D0 F4 BNE $F4 [$651E] A:00F0 X:0108 Y:00F0 P:envMxdIzC
--- End code ---
a full loop over almost everything
--- Code: ---$C1/651E 9D 0A 7D STA $7D0A,x[$7E:CD3A] A:00F0 X:5030 Y:00F0 P:envMxdIzC
$C1/6521 E8 INX A:00F0 X:5030 Y:00F0 P:envMxdIzC
$C1/6522 E8 INX A:00F0 X:5031 Y:00F0 P:envMxdIzC
$C1/6523 E8 INX A:00F0 X:5032 Y:00F0 P:envMxdIzC
$C1/6524 E8 INX A:00F0 X:5033 Y:00F0 P:envMxdIzC
$C1/6525 E0 00 01 CPX #$0100 A:00F0 X:5034 Y:00F0 P:envMxdIzC
$C1/6528 D0 F4 BNE $F4 [$651E] A:00F0 X:5034 Y:00F0 P:envMxdIzC
--- End code ---
$92 seems to increase with every sprite?
no real idea.
7E:7D0A to 7E:7E06 (+/- 3) seems to be reserved for the animations and 7E:7E0A is the next thing.
from there on seems to be general graphics, increasing
$C1/6525 E0 00 01 CPX #$0100
to CPX #0160 survived even ice3
...
we don't happen to have free $0200 RAM somewhere, do we?
Praetarius5018:
I'm actually disappointed that this works...
I just took the sprite counter and capped it at the last safe value. That's it.
Freezing it a low value would play no animations.
I simply replaced
--- Code: ---$C1/6BDE E6 92 INC $92 [$00:0092] A:0050 X:00FC Y:000E P:envMxdIzC
$C1/6BE0 E8 INX A:0050 X:00FC Y:000E P:envMxdIzC
$C1/6BE1 E8 INX A:0050 X:00FD Y:000E P:envMxdIzC
--- End code ---
with (via JSL of course)
--- Code: ---A5 92 LDA $92
1A INC
C9 3E CMP #$3E
90 02 BCC $02
A9 3E LDA #$3E
85 92 STA $92
C2 20 REP #$20
0A ASL A
0A ASL A
AA TAX
7B TDC
E2 20 SEP #$20
CA DEX
CA DEX
6B RTL
--- End code ---
even Ice3 - which so far had the highest problem rate - worked against 8 enemies, not even glitchy color changes. has a bit slow down/sprite flicker, but what'cha gonna do.
just for security, also replace:
--- Code: ---$C1/6528 D0 F4 BNE $F4 [$651E]
--- End code ---
with BCC $F4
in case it overlaps somewhere else...
that leaves only one mistery - why does a single target move vs the 8th enemy target the 1st player
edit:
ah no, that bug is better!
it does not target the 1st player, but the one "before" the current user; except in 1st player case it just does whatever because of index underflow
edit2:
just put EA at $C2/9517 and that's it... what.
Praetarius5018:
--- Quote from: Praetarius5018 on June 23, 2017, 04:25:22 PM ---I simply replaced
--- Code: ---$C1/6BDE E6 92 INC $92 [$00:0092] A:0050 X:00FC Y:000E P:envMxdIzC
$C1/6BE0 E8 INX A:0050 X:00FC Y:000E P:envMxdIzC
$C1/6BE1 E8 INX A:0050 X:00FD Y:000E P:envMxdIzC
--- End code ---
with (via JSL of course)
--- Code: ---A5 92 LDA $92
1A INC
C9 3E CMP #$3E
90 02 BCC $02
A9 3E LDA #$3E
85 92 STA $92
C2 20 REP #$20
0A ASL A
0A ASL A
AA TAX
7B TDC
E2 20 SEP #$20
CA DEX
CA DEX
6B RTL
--- End code ---
--- End quote ---
well, I found at least one case where it doesn't work properly - axes.
They skip a lot of indexes and go straight from 9 to $50 and that obviously works.
praying...
--- Code: ---A5 92 LDA $92
1A INC
C9 50 CMP #$50
B0 06 BCS $06
C9 3C CMP #$3C
90 02 BCC $02
A9 3B LDA #$3B //3C already leads to some graphic glitches for Flare
85 92 STA $92
C2 20 REP #$20
0A ASL A
0A ASL A
AA TAX
7B TDC
E2 20 SEP #$20
CA DEX
CA DEX
6B RTL
--- End code ---
edit:
had to lower limit from #$3E to #$3C
Navigation
[0] Message Index
[#] Next page
Go to full version