garou-hitboxes.lua

Finally, work is more or less complete on the Fatal Fury series hitboxes, now including RBS, RB2 and MotW. Due to the significant differences from the KoF series, the script has been split into a new file. Some of the relevant disassembly can be found here (local copy). As usual, this script works with both parents and clones.

RBS

RB2

MotW

As mentioned earlier, I had been unable to get the later games working because the memory where the box parameters is stored was changing by the time Lua could access it. The way it works is an address can hold one of several values, depending on the state of the "memory bank" setting. The bank is normally changed many times per frame. You can control it by writing a word to a certain address, and the correct value to get hitbox data depends on the character. There doesn't seem to be any ill effects from poking it as long as you restore it to whatever it was before.

The reason none of these games seem to work in FBA-rr may be due to the more limited range of memory it can access, as noted by ESN. FBA apparently can't reach the bank control.

Box scaling is now implemented for characters in the back plane, though at this time they don't line up exactly with the built-in hitboxes. The code for back row downscaling is mostly unchanged throughout the whole series. Multiply the box dimension by an eight-bit scale value, then arithmetic right-shift eight times. If the scale value is at max, the dimensions remain unchanged. Interestingly this code also shows up in MotW, even though the multiple planes were scrapped for that game.

Mauve was the one who first dealt with bank switching and box scaling in the ss5sp script.

I had trouble showing invulnerability frames before because I couldn't find a place in the character's memory space that governed invuln status. All of an object's properties are ultimately determined by the pointer at the beginning of the memory space, which is executed every frame. I had the script go to where the pointer says and read word by word until it either hits a return instruction or jumps to a subroutine characteristic of vulnerability or invulnerability. Moves with limited invuln (like RB2 Kim's hien zan) also need to check a memory value, so Lua does that too.

It's basically a crude disassembler. It seems to work well, but due to the ad hoc nature in which everything is handled I can't guarantee it's as good as the other scripts accuracywise. The alternative was to make breakpoints control everything. I wanted to avoid that because it's disruptive to the user experience. In the end I did have to use BPs for FF1 and FF2 vulnerability. You'll only get green boxes without them.

Speaking of breakpoints, the most painful and time-consuming task was getting the throwboxes out. Practically every type of throw is controlled by its own code that needed to be tracked down and studied, and sometimes given its own breakpoint. In fact, FFS, RB1, and RBS have so many BPs that they had to be broken into two commands due to the debugger console's 256 character limit. This is also part of the reason why about three quarters of the lines in this Lua script are game-specific code, compared to about half for the other scripts. The worst was FF2 and FFS, which check for normal throws in the wrong order: range before buttons. Seriously, this part sucked.

There are no throwability boxes, and all throws grab the opponent's axis. (The exception is FF3 normal ground throws, which can grab any vulnerability box.) However, the range of non-special throws does depend on the opponent, in that the character IDs of both the attacker and defender are used to determine where the range value is looked up from a big table. The range also depends on if the opponent is front or back turned. It might be possible to use this information to make proper yellow and white boxes, but there's no guarantee they'll be constant in size in every matchup, which would be the whole point.

In the Capcom scripts I was able to get throws drawn on "frame zero" by inserting them into the framebuffer upstream by one frame when they are detected. This doesn't work with NeoGeo because there is no framebuffer: all the boxes have to be drawn as soon as possible once acquired or else they'll lag behind the sprites. So throwboxes appear one frame late.

---

The KoF games have been moved to their own file. The only user-facing change at this time is to fix to the ghost boxes problem reported by phoenix. With no games left, "neogeo-hitboxes.lua" has been retired, but it'll probably be brought back if more NeoGeo titles are covered.

A small new feature added to all the scripts is the no_alpha option at the top. Setting it to true makes all box outlines full opaque and fillings full transparent. It's just a quick way to set up screenshots with the background removed without messing with the individual values. I couldn't set it to a hotkey cuz we ran out of hotkeys.

Comments

[error1]

impressive

[timmytheturtle]

Well done !

[dammit]

Thanks. I would have rather had a simple job than an epic struggle, but anyways, it's done.

[alexander]

sorry for the offtopic, but do you know if the fba used on ggpo has input delay?

[dammit]

Good question but I have no idea. Actually it's three questions:
1) How much delay does GGPO have offline?
2) How much delay does GGPO have online?
3) How does that compare to real hardware?

Probably someone's already researched this, but you can always set up an experiment like "Testing CCC2 For Input Lag" if you have the right equipment.

[CraigScott]

awesome, thank you for your dedication to the cause !

[dammit]

It's what I do.