Animated Hitbox Data!

[Dammit]

Not at once, it's just if you are fighting juli/juni it's player 3 and 4.

Here's a save state where it happens.

Thanks. Now flip invulnerability is shown correctly, and it supports more than 2 players:

Funny story from yesterday: Kajoq was theorizing a rushdown pattern with leilei against bishamon because it was working against a couple bishamon players that give him headaches, MightyMar overheard this theory and was like "We'll see about that, let's load the hitbox viewer" couple minutes later he said "that's going to lose to j.LK or backdash LK", then they argued and so they played... MMar was right. LOL

That's great, just what this is intended for.

Felineki: Thanks, that should be enough to add SF2. BTW, we saw your HF romhack, good stuff.

[Xenozip.]

Just a semi-random thought/question: what are the prospects of a neogeo/samurai-shodown game being implemented? More to the point, Mauve has created hitboxes viewers for IaMP, SWR, Blitz, and Melty, and has assisted with Arcana Heart and others. I'm pretty sure he knows his way around (people usually ask HIM for things, like the BlazBlue viewer). He basically took the Caster netplay programs and overhauled them from the ground up for IaMP and Blitz (and technically Melty, cept not really). Maybe there's something to point him in the right direction? I mean, I think he could probably figure out most things but I don't know about any of this stuff so I wouldn't know what to say to him as far as where to begin.

But to be fair, I don't know if this is apples and oranges or not, sorry!

[Dammit]

Integrating the info for more games and adding checks for special cases is the easy part.

The hard part (which mz and felineki have been doing) is finding the memory addresses that tell you where and how big the boxes are. Getting them requires a complicated procedure: use the mame debugger to watch for changes in an address you already know, like the lifebar, dump all the processor's activity to a trace file, and follow the instructions backwards. At some point the game compares an attack box to a vulnerability box. Keep tracing backwards until it leads to something that looks like an address. Sometimes you get a pointer instead, an address to an address.

The NeoGeo uses a Motorola 68000, the same CPU as CPS-1 and CPS-2 (and Sega Megadrive). So it's a plus if Mauve has experience debugging for those, but not necessary. mz and felineki can give more details on the how-to.

[Buttermaker]

Now flip invulnerability is shown correctly, and it supports more than 2 players:

Awesome, thanks! That also fixes the Alpha Counter invulnerability issues I came across.

[felineki]

On the subject of SF2 hitboxes, here's a bit of trivia: The CPS1 SF2s had an additional 6th hitbox type, a "weak point" box. This is what determined the counter damage for Blanka's rolling attack in WW. Additionally, every character's dizzy animation has this box present, so perhaps at some point in development it was intended for dizzied characters to take additional damage. The reason they don't in the final games is that the presence of the box on its own does nothing, an additional parameter has to be set for the damage multiplier to engage upon hitting the weak point box. Apparently this additional parameter was accidentally left on for Ryu's dizzy animation in WW which is why he takes double damage when dizzy.

In ST, it would seem that the weak point box system is entirely gone, there are only 5 box type pointers at the start of each hitbox list. However the character animation data still seems to have 6 hitbox pointers.

[Maj]

Whoa, i've never seen that documented about WW Ryu's dizzy state before, but i ran into it while messing around with a Ryu vs Ryu clip. Got him dizzy and hit him with two-hit uppercut and it did hellllla damage. Guess that explains it.

[felineki]

It's apparently somewhat well-known in the Japanese community. It's usually referred to as "byoukimochi no Ryu", which is something like "sick/sickly Ryu".

[felineki]

I'm going to take notes here while I do some research for potential games to be added to the script

Marvel Super Heroes VS Street Fighter

Player Base: 0xFF3800
Player Space: 0x400
Left Screen Edge: 0xFF4ACC
Top Screen Edge: 0xFF4AD0

Projectile Base: 0xFFD7D6
Projectile Space: 0xC0

X Position: 0x0C
Y Position: 0x10
Animation Frame Pointer: 0x40
Vulnerability Table: 0x6C
Attack Table: 0x6C
Push Table: 0x6C
(Seems that hitboxes aren't categorized... they're all in one big list and just loaded to the necessary slot)
Vulnerability 1 ID: 0x75
Vulnerability 2 ID: 0x77
Vulnerability 3 ID: 0x79
Attack ID: 0x7B
Push ID: 0x7D(?)

Box Definition:

Hval: 0x00
Hrad: 0x02
Vval: 0x04
Vrad: 0x06

Attack box definitions don't store attack property data, so they're still only 8 bytes long.

Y axis seems to be reversed in comparison to other games, negative = up, positive = down.

Night Warriors/Vampire Hunter

Game Phase: ???
Left Screen Edge: 0xFF8F18
Top Screen Edge: 0xFF8F1C

Player Base: 0xFF8388
X Position: 0x10
Y Position: 0x14
Animation Frame Pointer: 0x1C
Hitbox List Pointer: 0x5C
Player Space: 0x500

Projectile Base: 0xFFA86E
Projectile Space: 0xC0

SF2-Style Hitbox List:

Vulnerability Table: 0x00
Weak Table: 0x06
Attack Table: 0x08
Push Table: 0x0A

Box ID pointers in animation data, SF2/SFA2-style:

Vulnerability ID: 0x10
Weak ID: 0x13
Attack ID: 0x14
Push ID: 0x15

Box Definition:

Hval: 0x00
Hrad: 0x02
Vval: 0x04
Vrad: 0x06

Attack ID Space: 0x10

[Dammit]

Regarding SF2: I think I got the right numbers punched in for all five games, and the script is updating with each animation frame, but the boxes are wrong.

The debug stuff at the upper left is just the x and y offsets of the big axis, and the hval, vval, hrad and vrad of the individual boxes.

The current draft is here: http://lua.pastebin.com/5hE9SiZE
I need help figuring out what's wrong.

I thought we might do SF2 in a separate script because of the substantially different hitbox routine, but if other older games like Vampire are like it, it might be better to keep them all together.

About that "weak" type: is it just a flag or does it have its own boxes?

[felineki]

It's an actual box, it's displayed as such in the Object Test mode of the CPS1 SF2s:

Ryu's dizzy animation. The displayed hitbox here is his Weak box of ID 01 (like I said earlier, all characters apparently have this box present on their dizzy animation for whatever reason).

I might have messed something up in my documentation attempt earlier, I'll take a look and see if I can come up with anything.

EDIT: I found the problem. You're still multiplying the box ID values by 8, it should be 4 (or 16 in the case of attack). Fix those and it works beautifully:

[error1]

weird, many of the hit boxes work right but half of them are way off, I couldn't get it to work with the cps1 game

edit: also gen seems to break it, in sfz2a at least
also also shin akuma has bigger hit boxes the regular akuma, those cheating basters lol, this is awesome

[Dammit]

Thanks, I had a similar mistake for the other games. After some cleanup SF2 will be just about done.

http://lua.pastebin.com/Bg55w8cD

Works fine in all the games but the red boxes on some of Dhalsim's long attacks are set behind instead of in front. Maybe there's another byte in the attk ID at work.

The Weak boxes should be working.

gen seems to break it, in sfz2a at least

What's wrong with sfz2a Gen? Besides being sfz2a Gen.

[error1]

nothing that needs fixing, it just seem like the hitboxes go away sometimes vs cpu controled gen, might just be his stage or something, but I tried it and it worked fine with a human gen.

[felineki]

When messing around with the hitbox move/resize function of the Object Test, it would seem that the system somehow keeps track of where the box should be even when you move it in such a way that one of the coordinates rolls over. So there must be something else going on there. For those Dhalsim attacks, the addresses where I'd expect to find the x offsets are 00, but the Object Test is pulling numbers from somewhere...

EDIT: It would seem that sometimes the value for their "Hit Type" parameter (byte 0x05 of the atck box definition data) is used as the x offset for the atck box, overriding the default x offset value. I don't know what exactly triggers this however. Since the maximum offset without invoking this system is +-0x7F, I'd say if Hit Type is >= 0x80, then use it as the x offset.

[Rufus]

... For those Dhalsim attacks, the addresses where I'd expect to find the x offsets are 00, but the Object Test is pulling numbers from somewhere......I don't know what exactly triggers this however. Since the maximum offset without invoking this system is +-0x7F, I'd say if Hit Type is >= 0x80, then use it as the x offset.

Do any other attack hitboxes have the x offset at 0x00?

[felineki]

Looking at the ASM, it does seem to be as I thought: If Hit Type is 0x80 or over, it's used as the x offset. The reason the regular x offsets are 00 for Dhalsim's long limbs is probably because there was no reason to set them since they were going to be overidden by the Hit Type value.

[Dammit]

All done and polished up.
http://mame-rr.googlecode.com/svn/lua/sf2-hitboxes.lua



Dhalsim attacks are looking good with the fix. Added HSF2, which gets around that problem by using two bytes instead of one for box dimensions.

Edit: Added a BLANK_SCREEN option that makes it easier to do stuff like this. Use Lua hotkey 1 to toggle.

The CPS1 SF2s had an additional 6th hitbox type, a "weak point" box. This is what determined the counter damage for Blanka's rolling attack in WW. Additionally, every character's dizzy animation has this box present, so perhaps at some point in development it was intended for dizzied characters to take additional damage. The reason they don't in the final games is that the presence of the box on its own does nothing, an additional parameter has to be set for the damage multiplier to engage upon hitting the weak point box. Apparently this additional parameter was accidentally left on for Ryu's dizzy animation in WW which is why he takes double damage when dizzy.

What's the parameter?

[Xenozip.]

Nice. http://bit.ly/9HrLYd

heh http://bit.ly/aiZCd7

[felineki]

What's the parameter?

"Weak No." as it's labeled in the Object Test, it's byte 0x12 in the animation frame data. It seems that by default it's 00, which means do nothing, and that setting it to 02 invokes the double damage factor upon hitting the weak box.

Upon checking in the Object Test, it appears that in Ryu's WW dizzy animation only the frame where he is leaning forward the most has that parameter set, so he won't take the double damage unless you hit him during that frame.

[Dammit]

Alright, got it fixed so the Weak box is only shown when Weak No. is over 0:


I think I am satisfied with this one.

http://bit.ly/aiZCd7

Emtpy image?

[Xenozip.]

http://bit.ly/aiZCd7

Emtpy image?

oops, try http://bit.ly/cdyKQx

[mzk]

This is awesome, thank you felineki and Dammit.

I can be a better player now:

I had autofire only set for LP, but it seems HP is much better.

[Xenozip.]

Speaking of autofire, is there a way to inspect replay files to see if some one is using autofire?

[Dammit]

oops, try http://bit.ly/cdyKQx

Makes you wonder why they couldn't make the red match up with the sprites. But the SF2 hitbox code is so pathological that I wouldn't be surprised if some of these cases were just caused by developer confusion.

Speaking of autofire, is there a way to inspect replay files to see if some one is using autofire?

Here's a little test: JoyToKey autofires the buttons. Macrolua records it and converts to line by line format.
http://pastebin.com/TnpL89tJ

The nominal rates are 5, 10 and 30 Hz for buttons 1, 2 and 3. The higher speeds are more inconsistent (and look more realistic) due to sampling error. With internet lag it's going to smear out even more. So it would be pretty hard to detect even if you could get the rec in an easily analyzed form. Maybe a better sign is looking at when the autofire is active. I'd think a skilled player would know just when to start and stop mashing, to avoid getting tired and distracted.

For my part I have no problem using autofire or having it used against me in casual play...

[Xenozip.]

oops, try http://bit.ly/cdyKQx

Makes you wonder why they couldn't make the red match up with the sprites. But the SF2 hitbox code is so pathological that I wouldn't be surprised if some of these cases were just caused by developer confusion.

Or maybe Capcom just likes doing stuff like that.
http://vsav.mizuumi.net/images/2/27/Lilith-fmk.png
http://vsav.mizuumi.net/images/8/8b/Mori_sMK.png
lol.

Speaking of autofire, is there a way to inspect replay files to see if some one is using autofire?

Here's a little test: JoyToKey autofires the buttons. Macrolua records it and converts to line by line format.
http://pastebin.com/TnpL89tJ

The nominal rates are 5, 10 and 30 Hz for buttons 1, 2 and 3. The higher speeds are more inconsistent (and look more realistic) due to sampling error. With internet lag it's going to smear out even more. So it would be pretty hard to detect even if you could get the rec in an easily analyzed form. Maybe a better sign is looking at when the autofire is active. I'd think a skilled player would know just when to start and stop mashing, to avoid getting tired and distracted.

For my part I have no problem using autofire or having it used against me in casual play...

Hmm, that's interesting. Well I was just curious anyway since the subject came up in conversation, but it's not a matter of necessity. I agree that it hardly matters in casual play (actually I think autofire would be more detrimental than beneficial in most games), but just knowing if it's possible to dump replay data in a way that the inputs could be "viewed" is what I was initially wondering. Because that would also let us see how certain players are executing particularly esoteric tech.

[felineki]

oops, try http://bit.ly/cdyKQx

Makes you wonder why they couldn't make the red match up with the sprites. But the SF2 hitbox code is so pathological that I wouldn't be surprised if some of these cases were just caused by developer confusion.

I think it's that they wanted that move to miss against crouching characters, regardless of the graphics. They seem to have put some effort into making crouching characters' vulnerability stay below a certain limit, a good example is Zangief whose crouching vulnerability is lower than his sprite would suggest.

[Xenozip.]

Err, hey, so the script works for SSF2T?

I mean, I know it works for hsf2 but was wondering if it worked for just vanilla ST.

[felineki]

Yeah, it works for ST. The Ryu VS Ken pic I posted earlier was ST.

Anyway, I've... sorta, kinda, partially got it running for Night Warriors/Vampire Hunter:

Still a lot of bugs to work out. I'm updating my previously posted notes as I experiment.

[Xenozip.]

Weird, when I load it up in ST (ssft2 rom) it says it's displaying data for ssf2, and nothing happens. Do I need a particular romset or something?

[felineki]

Weird, when I load it up in ST (ssft2 rom) it says it's displaying data for ssf2, and nothing happens. Do I need a particular romset or something?

It looks like ST's MAME structure was updated recently (no longer uses SSF2 as a parent), so you might want to try and find a newer ROM.