secrets

Breakpoints/watchpoints in FBA

FBA-rr 0.0.7 implements some new Lua functions:

memory.registerexec	trigger a function when a given code is executed
memory.registerread	trigger a function when given memory is accessed
memory.registerwrite
memory.getregister	read from and write to the CPU registers
memory.setregister

This effectively makes breakpoints and watchpoints available from within Lua. You can thank mz for these developments.

Most of the scripts have been updated to use these functions where applicable. In particular, if you want to see the CPS2 and Marvel throwboxes without messing around with MAME-rr, now you can.

In fact, the old method of piggybacking on the MAME-rr debugger has been removed, because I oppose writing to memory when the script is supposed to be read-only. So you have to use FBA for the bp/wp functionality now, but MAME still works for everything else.

The exceptions are garou-hitboxes.lua, since FBA's Lua can't control the NeoGeo's bank switching, and cps3-hitboxes.lua, since the new functions don't support the SH2 processor, although it's only one breakpoint at stake there. (It may be possible to get garou working in FBA by getting to script to read the box parameters exactly when the game's program does, which would obviate bank switching.)

The overhaul process was unexpectedly painstaking:

Samurai Shodown & Last Blade BG removal

In honor of Mauve's recent hitbox work and recognizing that someone might want to systematically catalog the hitboxes, I've developed background removal codes for the later Samurai Shodowns and the Last Blade games. (Only ss5sp has a hitbox script right now.)

These are of course also useful for general sprite ripping. As with all NeoGeo games, you can adjust the background color by editing one value.

http://www.mamecheat.co.uk/forums/viewtopic.php?p=13476#p13476

Random damage in SF2

Everyone knows there are random elements in the SF2 engine, including the amount of damage and stun done by most attacks. But what kind of randomness, exactly? Here are the general rules:

attack type	random dizzy	random damage	lifebar scaling*
non-throws	yes	yes	yes
normal throws	yes	no	yes
multi-hit throws	yes*	no	yes
command throws	yes	depends*	yes

• I didn't examine lifebar scaling in depth, but a little testing can confirm T.Akiba's findings. Just set the opponent's life to 30 and see the difference.
• Some holds like Blanka's and Balrog's always do no dizzy.
• Throws do fixed damage except the following:
  • Gief's SPD (SSF2 and SSF2T versions only)
  • Gief's close 360+K, 2nd hit
  • Gief's far 360+K
  • Gief's super, 3rd hit
  • Hawk's super, 2nd hit
  • Vega's super, 3rd hit
  • Honda's oicho, both hits

Now for the details. To reveal the exact damage and dizzy formula for all attacks and help compile more accurate attack data, I developed the following breakpoints for use in the MAME debugger:

breakpoints	helper Lua script
(local copy)	(local copy)

You run MAME with the -debug switch on, then copypaste each of the bp lines for your game into the console. Then anytime either player gets attacked, the damage and stun info is displayed there. Since the FBA/MAME-rr Lua implementation doesn't support breakpoints, there's no pure-Lua way to get the formulas. What the helper script does is it prints out damage/stun/timeout dealt whenever someone gets hurt. You can use it to more easily verify that the formulas jive with the real figures.

(There's supposed to be a way to enter multiple commands at once, but it doesn't work. Also, these will only work on the current parent ROMs, not clones. However, every ROM address is given relative to the breakpoint address, the pc, so getting these to work with a clone should only require offsetting the bp by a constant value.)

How random damage works: there's a base damage for every hit, then a random value is added. The random values are looked up from a table of 32 possibilities, with the actual one selected determined by the output of a pseudorandom number generator. The sum is then scaled down by a certain factor and rounded up to produce the final damage.

The lookup table is dependent on the attack, and all the relevant random number tables are included in the bp file. The scale factor, however, is dependent on the opponent: it's a defense rating.

SF2 codes and random findings

I've been developing improved cheat codes for the SF2 games for the official MAME pack. Since I'm instructing Macrolua users to use cheat codes to control variables like frameskip and stage choice, I figured it would be good to have clean code files available for everyone.

The current SF2 XMLs (0.142) are packed with inefficient and in some cases ineffective codes to the point that you don't even want to look over the list. Some of them are relics from the primitive cheat engine, and some of them are just ill-conceived. Rather than tell Pugsy they're crap and should just be removed (which probably wouldn't go down well), I renovated nearly all the codes in the collection for all six games. The official pack won't be updated until after 0.143 comes out, but the results are here.

Noteworthy codes:

• infinite life that lets the opponent go into proper hitstun
• prevent the slowdown from projectile impacts
• stage select, including bonus stages
• freeplay for [ssf2t], which doesn't have one in the op menu
• TAP power selector, which tells you exactly how much charge each level needs
• button-mash moves that require only two presses
• control the ending and boss in single-player

---

Along the way I learned some things I didn't know:

Turbo speed frameskip, revisited

This is an update to an earlier post.

I've determined the frameskip patterns of the Capcom NAOMI games, gotten better figures for HF and ST, and added a few console versions for comparison. These things were made easier by an improvement to my old frameskip-analyzing Lua script. Now it requires less info about the game than before, it's less subject to game-specific quirks, and has auto game detection for arcade emus: http://pastey.net/149881

It's the same basic technique as before: watch how the timer value goes down frame by frame under each speed setting, then extrapolate the skip patterns. The experiment itself is easy, but setting it up was painful for NAOMI games because they run at 5-10% on my computer and savestates don't work. Just getting into the operator menu, rebooting the machine and starting a match takes a lot of in-game loading time.

The memory addresses for the NAOMI game timers aren't in any cheat databases so I had find them myself. The search isn't hard, but the memory used by MAME shoots up several gigabytes when you cheatinit, and I had to borrow another computer with more RAM to avoid an Out of memory! crash. Even without doing that I only have enough memory to start capsnk and mvsc2 in MAME-rr. Vanilla MAME can do the job since all you need is frame advance (shift + pause hotkey) and the mem viewer of the debugger, but it's even more tedious without Lua.

Was frameskip in any other games? It seems to have only been a Capcomism.

The tables below give the patterns in the usual form of numbers of consecutive unskipped frames separated by commas. The speed relative to no frameskip is also given. This is the total rendered frames divided by the displayed frames.

The last word on BG removal

Couldn't let it go without finishing the job.

I went back and found out how to remove the HUD for the last of them: the sf2 games, sfa, dstlk, nwarr and cybots. They all require ROM writes that dummy out the drawing that occurs at the beginning of the match, and the updating that occurs throughout the match. It's similar to the procedure for most of the NeoGeo games.

• MAME format

Took awhile, but it eventually dawned on me that the key to finding the right routines to patch out is to put watchpoints on the time, life and super parameters. The game has no reason to be reading them before the match start except to get the data to populate the HUD with. Then it's a matter of taking a look at the stack and NOPping out the function one or two steps up the chain. Or when that breaks something important, make the function return early, or unconditionally branch past the offending parts.

The rest of the BG removal codes

I went ahead and did this for the rest for the hitboxed games, threw in a few extra too.

• MAME format

The current tally:

sf2 sf2ce sf2hf ssf2 ssf2t hsf2 sfa sfa2 sfz2al sfa3 dstlk nwarr vsav vhunt2 vsav2 ringdest cybots sgemf xmcota msh xmvsf mshvsf mvsc

fatfury1 fatfury2 fatfursp fatfury3 rbff1 rbffspec rbff2 garou kof94 kof95 kof96 kof97 kof98 kof99 kof2000 kof2001 kof2002 kof2003 svc

• Boldface mean no ROM writes were required. That means they probably work both parents and clones and are easily convertible to FBA format.
• Italic means I was unable to get rid of the HUD.
• The BG color in all the NeoGeo games can be controlled by editing a single value.

More background removal codes

Continuing the work from last time, I came up with codes for the most of the hitboxed games.

• MAME format

removed BG	removed BG, parent only	removed BG except for HUD, parent only
xmcota msh xmvsf mshvsf mvsc	sfa2 sfz2al sfa3 vsav vhunt2 vsav2 kof96 kof97 kof98 kof99 kof2000 kof2001 kof2002	sf2 sf2ce sf2hf ssf2 ssf2t hsf2 sfa dstlk nwarr

CPS2 background removal codes

Thanks to some info passed to me by felineki, I've developed some "cheat" codes to hide the background layers and background sprites of some CPS2 games:

xmcota, msh, xmvsf, mshvsf, mvsc, sfa2, sfz2al, sfa3, vsav, vhunt2, vsav2

• FBA format
• MAME format

Improved CPS1 mute codes

I was working with SF2CE recently and realized that the mutecodes for the CPS1 games that I found earlier aren't very good. If you activate them during a match, the tones take forever to fade away. Plus, the music changes when someone gets near KO, so there is sometimes an odd tone when that happens, even if you activate before. This is really not much better than the old way.

There may not be a perfect solution possible from just zeroing out memory addresses. The way to get the job done precisely is with breakpoints. (Here I go again.) There are two objectives: execute the routine that makes the music stop, and prevent the routine that loads new tracks from being executed. These two lines accomplish exactly that, and they work for WW, CE and HF:

bp 00C0,audiocpu.rb@D7E1>0,{pc=006A;g}
bp 025A,1,{pc=030F;g}

You need to run MAME with the -debug command line option, then the debugger will steal focus when the game is loaded. Press F6 to switch to the audio CPU, otherwise it'll mess with the wrong CPU and won't work. Then enter those lines separately in the console. (Or as a single line with a semicolon between.) Press F5 to make the debugger return control to the main program, and click in the game window to get on with the game.