secrets

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.

Marvel pushboxes

I found the memory addresses responsible for deactivating the pushbox during moves that pass you through the opponent, like Captain America's cartwheel. In all five games it's just a one-byte offset from the character base that, if non-zero, skips the pushing check.

Why didn't I find it earlier? So little time passes between when the address is set and when it is checked and cleared that the changes can't always be caught by memsearch, or by memory.readbyte being run during emu.registerafter. In other words, those tools can only check the RAM between frames, but the memory is being altered for less than one frame.

Sometimes the script only catches the no-push state about half the time, causing the green box to flicker on and off during moves like mshvsf Hulk's forward dash. To solve this I cheated and had the script check the next frame in the framebuffer: if the pushbox is off then, deactivate it now as well. This mostly eliminates the flickering but is not really elegant. The framebuffer was implemented to make it so the boxes are drawn in sync with the sprites instead of 2-3 frames early. It's not meant for what I'm using it for. It's not really effective either: This trick doesn't even work for moves like mshvsf Blackheart's dash because the byte is never checked at the right time, so the green boxes never turn off.

This is similar to the throwbox dilemma: the information of interest is available only at a time or in a place that Lua can't access. But there's some good news. mz brought my attention to the fact that Gens has a function, memory.register, that runs a callback whenever a given memory address is written to, regardless of frame timing. Setting memory.register to watch the addresses in question would solve this pushbox problem, and would also enable the CPS-2 script to know when to draw throwboxes for SFA3 without having to rudely re-zero the throw ID bytes every frame.

Dizzy durations and limits

Update: see here

While developing the SF2 dizzy meter script I found that it's not enough to keep track of each player's stun points. It's also also necessary to know how high they could get before triggering the stun, and how long it lasts. So, that took some more experimentation and memsearching. I considered expanding the script to cover the other games but then thought better of it.

The memsearch results have been added to the dizzy articles on SF2/SFA and Marvel/Gem Fighter. What follows is a summary of some related observations.

In SF2, the limit is always 32. The durations depend on the icons and part randomness, but the order of severity turns out to be a little different from the popular convention:

icons	stun time (frames)
stars	90, 120
birds	150, 180
angels	60, 90
grim reapers	150, 210

It doesn't look like the icon selection is completely random either: The angels and grim reapers won't appear if the opponent just stands passively while getting hit.

Claw's claw

Vega is famous for his detachable claw. His punches have less range and damage without it, but it's a little mysterious what causes it to get knocked off.

In the SF2 series there's a counter that starts at zero and increments every time Vega gets hit or blocks. There doesn't seem to be any distinction between light or heavy attacks or normals vs. specials, but throws don't affect it. When the counter reaches 8, instead of increasing further when he's hit, there's a pseudorandom chance the claw will pop off. The probability doesn't seem all that small. It couldn't be less than 1/16.

In the games prior to ST, a dropped claw is irretrievable. In ST you can touch it to pick it up, and this resets the hit counter. This behavior is preserved in the respective HSF2 modes.

In SFA3 the counter goes the other way, from 8 to 0.

jojo and jojoba mutecodes

I finally found the music mute codes for the last of the CPS3 games, Jojo's Venture and Jojo's Bizarre Adventure.

https://macrolua.googlecode.com/svn/trunk/FBA%20examples/mutecodes.txt

This has got to be the fifth or sixth time I've looked for them over the past months. Previously I had tried the usual equals/less than/greater than approach and came up dry, probably because I was making false assumptions about when and how the volume was changing. Another downfall was that I was using the complicated and confusing MAME cheat engine, which I'll never touch again.

Unlike CPS1, CPS2, and NeoGeo, the CPS3 has no dedicated memory space for audio, and its main CPU space is much larger than the others. This makes the haystack bigger. I knew from the other CPS3 games that the address I wanted would contain the volume control for the music. The game code uses it to fade out BGM at certain transitions.

Marvel & Gem Fighter dizzies

Here's some more dizzy information to follow the SF2/SFA findings.

Unlike in the other games, the dizzy levels in the Marvel series start at a base value and count down toward zero as hits are taken. This makes it easy to see that different characters have different limits. Furthermore, there's a generous 180 frame window to continue building stun damage after each hit.

MVC is different from the others in that the stun limit is higher (80 instead of ~50-60), attacks do way less stun damage (one or zero points), and there's only 60 frames to land another hit before it resets. I can't say I've seen many dizzies in MVC, but then again I haven't played it much.

Turbo speed & frameskip, continued

update, May 2011

---

I previously did some research on frameskip patterns in Vampire Savior. Here's the followup.

To reiterate, an n in the frameskip pattern means on the nth frame, advance two frames instead of one. So a pattern of 3,3,3,... means every third frame advances two, and every fourth frame is skipped.

SF2 series

Game	Timer count/frame addresses	Frames per count
sf2	0xFF8ACE-F	30
sf2ce, sf2hf	0xFF8ABE-F	40
ssf2	0xFF8CCE-F	40
ssf2t	0xFF8DCE-F	40
hsf2	0xFF8BFC-D	40

hsf2	Frameskip pattern
TURBO 0	n/a
TURBO 1	5,5,6,5,5,6,...
TURBO 2	3,3,3,3,4,3,3,3,3,4,...
TURBO 3	2,2,2,3,2,2,3,...

SF2/SFA dizzies

Update: see here

A question came up earlier about dizzying in ST and HDR, so I decided to put my memsearch script to work.

I found that each player has two parameters that I named dizzy level and dizzy timer. Getting hit increases both values, and bigger attacks tend to cause greater increases. If dizzy level passes a certain value (which probably depends on the game and the character) you get dizzy, and dizzy level resets. Dizzy level is also reset if dizzy timer reaches zero.

(This is different from SF3, where stun damage decreases gradually when not being attacked, like how guard meter regenerates in SFA3. I have no information on how it works in SF4 but I'd guess it's more like SF3.)

Fooshido

Bushido Blade is a series of fairly awful fighting games for PS1. The selling point is no lifebars: you die in one hit. That's nice, but it kind of falls apart from there. Defense is too haphazard and it's all over too quick to really care.

Here's the rundown on the attack and defense system in BB2, which is simpler than and somewhat inferior to BB1.

If the opponent counters an O attack with X, or X with O, the result is a blue spark and the opponent recovers fast.

Memsearch / cheat codes for arcade games

Most of the tasvideos emulators come equipped with a memory search utility. This is a tool used to find the memory addresses that contain useful information like positions, timers, and energy reserves. The data can then be monitored to help plan routes and perform precise techniques, or it can be manipulated with cheat codes to change the way the game behaves.

Memsearch is pretty straightforward if you have an idea of how the parameter should change as the game is played. For example, the quantity that determines the current amount of vitality should decrease as damage is taken or increase when the bar is refilled. So you can tell memsearch to look for values that decreased or increased since the last search depending on what happened.

FBA also has a memsearch, but it gives no feedback other than the running count of possible addresses. Furthermore it's crashy when used in conjunction with savestates, or sometimes it crashes for no reason. FBA-rr adapted the superior memsearch interface from the other rerecording emulators, but it suffers the same crash problems.