The CPS2 hitbox script can now show throwboxes for all its supported games with the help of breakpoints. Throwability boxes have also been added, which as usual are enabled with hotkey 5.
The third user-relevant change is that the validity checks that determine when to not draw the boxes have been made more accurate for all the box types. So for example, the blue boxes in vsav will disappear exactly when the opponent can no longer be juggled, and white boxes won't reappear until exactly the frame when the opponent can be thrown again.
This was achieved by studying trace after trace of asm dumps, sometimes using breakpoints or watchpoints to manipulate branch results, rather than my old guess & check methods. In some cases the solution dropped in easily, but some required swathes of new code to handle correctly. Once again I found that newer games are more systematic, while older games do everything the hard way.
BPs are applied in the same manner as described in the random SF2 damage post. That means most throws can only show up in MAME-rr with the debugger active. However, you can continue to use the new version normally in FBA-rr or without the debugger and still get all the rest of the functionality.
The actual breakpoint command to put in is printed in the Lua console when the game starts. Just copy it in and hit enter. To make it less tedious for the user, it's set up so that all BPs are merged into a single line. The BP addresses vary between different romsets (parents and clones), but the script is set to automatically adjust to whatever version you are running. Occasionally the game may glitch up as the BPs are entered, but this only happens once. Reset or load a savestate to proceed.
Be sure to enter bpc
or bpclear
before quitting or running a new game or MAME-rr will crash. If you want to run MAME with the debugger without having to launch from a command prompt window every time, you can create a batch file with the launch command in it and then just double click the .bat file.
Since these breakpoints work by scrawling some data into RAM where Lua can read it, it's possible they can interfere with the normal operation of the game if that RAM space is used for something else. It's difficult to confirm for certain there's no interference going on. (Ideally BPs would pass the info directly to the script. And ideally the user wouldn't have to deal with any of this.)
As was done with SF2, throws are inserted one frame ahead in the framebuffer so that they'll be drawn on the exact frame(s) they are attempted and not one frame too late. If the boxes aren't showing up at all, sometimes ground throws don't get attempted unless the opponent is on the ground, and likewise for air.
Below I'll discuss some findings for each game.
sfa & sfa2 / sfz2al
Ground throws grab at the opponent's pushbox while throws from the air grab at the axis. To differentiate them, I made the latter orange. (You can change that of course.) Ground throws have no defined height, so I used the pushbox height, which looks good. Since the white box is meaningless in the air, it simply disappears when characters go airborne.
The throwability rules change during A2/Z2A custom combos: You can connect command throws during hitstun (but not blockstun). It's harder to notice, but CC throws also ignore the wakeup throw invulnerability. The script is faithful to this and the throwability check depends on the opponent's CC state.
sfa3
Throws were already working and this game requires no BPs. It does benefit from the framebuffer tweak, however, and they show up on the right frame now. Like its predecessor, the throw rules are different during VC—you can connect command throws during hitstun and blockstun and on a fully floored opponent. The script reflects this, and changes its behavior accordingly. (Gen's Kouga isn't having any of that and only cares about the pushbox.)
Attack boxes in "friends" supers, like Gallon's, Rose's, and A3 VCs are now correctly colored as non-projectiles.
Regarding A3 Rolento's tripwire: It has its own box type now which means the color is more easily customizable. It was being drawn for a little while after it stopped being active, but this is now fixed. In A2, it's shown like all other ground throws.
dstlk & nwarr
These two gave me the most stress out of this whole set. They do all the throw stuff in a proprietary way, with even some differences between them.
Only the frontal range is defined for ground throws, and it's hardcoded for Midnight Pleasure. Vulnerability range is a constant value for each character. In dstlk, Anakaris's grab goes for the white box. In nwarr it checks for the axis, as do Water Jail and Hell Dunk. They really can grab an opponent beneath the floor, but there may be no legit way to set that up.
All the ground throws show up without breakpoints, but since the game's code checks range before any box data is loaded, you have to get within throw range for the box to come out. The interesting thing is that all normal and command throws take a couple frames to start, all have a whiff animation, and they all have multiple active frames with increasing range. That's hard to observe when you have to make the opponent quickly get out of the way, so one of the BPs forces ground throws to be attempted at any range. Ironically the whiff animation is unthrowable.
These games compute airthrows by a complicated and aggravating system that compares axis positions, character-specific horizontal and vertical offsets, and a hardcoded vertical range of 12 pixels. The way I ended up rendering it, when you jump, the white and yellow boxes shrink to a strip, so you have to line up yours with the opponent's to land it. There's also a hardcoded minimum height of 48 pixels off the ground to attempt the throw.
To make matters more difficult, the game's code checks whether airthrows are in range before even checking if anyone is pressing the right buttons. That means if I set the breakpoint on the range check, the yellow box will show up even if no one is pressing anything, but if set on the button press part, it will only show if it's already in range to connect. I ended up putting the BP earlier and then simulating the button press checks in Lua (that line with bit.bnot
) to get the box drawn at the correct times.
vsav / vhunt2 / vsav2
Like A3, the pushbox is used for throwability, and like A3 all the machinery for preparing the throwboxes was already in the script. The only missing ingredient was the IDs, which are supplied by the breakpoints. Normal throw ranges are short, especially airthrows, which are just a tiny notch.
ringdest
Not much to say here since throws were already working. No breakpoints were needed, but the improved checks for pushability and projectile validity make things look nicer. The pushbox really does disappear during impact freeze. Also, the camera coordinates are now read as signed instead of unsigned so stuff doesn't flicker when the screen shakes.
cybots
This game has a proprietary way of loading both throw and throwability boxes, but at least all four parameters are given. Ranges tend to be really short with a few exceptions.
OTG hits and throws seem to be pretty important in cybots.
I had trouble finding a clear place in RAM to put the BP data and ended up cramming it at the very end of the player space. Hopefully it doesn't interfere with anything there. Actually the box parameters are being copied from another place in RAM, but they can't be read reliably without a BP because they get changed immediately after being used. It appears that although a vertical range value is drawn from ROM along with the other params, the horizontal range is used for both X and Y. This is probably a glitch. The upshot is all yellow boxes are perfect squares.
I also discovered the camera coordinate addresses vary depending on stage, which means the old version was wrong on some stages. This is fixed.
sgemf
This game has well-behaved throwboxes like A3 and vsav. There is a dedicated throwability box but it seems identical to the pushbox.
Players are throw-invuln during the startup and active part of any move other than throws (Gief's SPD excepted) and the special button attacks. A somewhat easy way to test this is with Felicia's electricity or Lei-Lei's delayed QCF+P. They can't be thrown even though they're just standing still. This has to be either a glitch or a terrible design call.
If you played around with the earlier version you would have seen that juggled players are covered by a seemingly harmless red box. It's only supposed to be able to hit if the opponent got dizzied around the world, and this is fixed now.
Wow, amazing update. This must have taken a lot of work. Thanks a lot.
Posted by: felineki | 07/22/2011 at 12:47 PM
Thank you so much, you must have some idea how important this update is. So many mysteries to reveal. Thank you!
Posted by: Xenozip | 07/22/2011 at 06:09 PM
Thanks. While it's definitely more fine tuned I can't guarantee it's perfect, which is what I was aiming for. Let me know if anything feels wrong.
Posted by: dammit | 07/23/2011 at 01:32 AM
http://i.imgur.com/1HOWM.png
Yeah, this isn't right. The third active throw of zabel's hcb+p throw.
Posted by: jedpossum | 07/24/2011 at 04:49 PM
never mind the command it was a regular throw that has a whiff animation for some reason.
Posted by: jedpossum | 07/24/2011 at 05:07 PM
Strange, the offset from his throwbox data is 1 for that box. Only even numbers make sense since the range offset is read as a word, so I fixed it by making it reject odd values. It seems the address is used for something besides throws. Anyways, thanks for reporting that.
Posted by: dammit | 07/24/2011 at 06:59 PM
So the normal throws whiffing is part of the code.
Posted by: jedpossum | 07/25/2011 at 06:25 PM