secrets

SimCity grid viewer

Someone emailed me asking for one of my old Lua scripts, since the place I left it, pastey.net, is down. Rather than just send along my archive copy, I gave it an overhaul.

• http://pastebin.com/VhBbXbY8
• http://dammit.typepad.com/files/simcity-grid-viewer.lua

It's for the SNES version of SimCity and it draws a grid showing important parameters like land value and growth rate on the playfield, along with the values of each square in the grid. It also marks the city center tile, which is important for some computations. FatRatKnight was the one who found the key memory addresses. (The grid without the numbers is available in the in-game map, but it's really slow to load and it's squeezed into a small window, so it's hard to use.)

SF2 throwboxes

Some time ago I found out about throwboxes in Marvel, SFA3 and later KOF. I was disappointed to find they couldn't be shown in vsav or SFA2 with the current tools because the box dimensions never actually get written to memory in those games.

I assumed the same for the SF2 series since it's older, but it turns out the data is just sitting there at 0x64 after the character base. It was right there the whole time. So, I was able to update the SF2 Lua script to show them for this game.

Like SFA3 and KOF, the data doesn't get cleaned after it's used, so I am forced to make the script write zeroes there to keep from drawing old throws. This time, I took the trouble to ensure that throw attempts are correctly drawn on frame zero rather than frame one, when normal attacks start animating. This required some messing with the framebuffer code. I should probably go back and do this for the other scripts as well.

And like KOF, there's a box just for throw vulnerability, centered horizontally on the char's axis. With the current checks, it should disappear at unthrowable times, like during DP startup. I also made it different colors for ground and air throwable states (white and almost black) because there are some moves in SF2 where it's hard to tell. Remember to hit hotkey 5 to show throwable boxes.

Here are some random observations.

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.

More Fatal Fury boxes

Turns out the memory reading problem doesn't apply to the earlier games in the Garou series and I was able to show boxes for Real Bout 1, Fatal Fury 3, FF Special and FF2. I ran out of month before I could do Fatal Fury 1 and I want to move on. Each game is on a slightly different system, go figure.

The memory lies

Despite failing to show the blue and red boxes in the Fatal Fury games, I decided to continue on and study the throw system. This led to an unexpected discovery.

Try running Garou with the debugger (mame garou -debug) and enter this breakpoint in the console:

bp 028928, 1, {printf "char base=%x, throw base=%x, throw data=%016x", a4, a1, maincpu.rq@a1; g}

(That's all one line.) Now whenever a throw is attempted it'll print out the parameters, including the range. The fourth byte of the data is the frontal range and the fifth and sixth are vertical range, which is zero for ground throws. Command throws have multiple active frames and print more than one line.

In order for throwboxes to work in the script, it needs to know two things: is a throw being attempted right now, and what are the grab ranges. The same principle applies to any kind of box, but the others usually make their presence known continuously in RAM where the script can read all about 'em. However, throw attempts in this game leave no telltale sign in RAM, which is typical as I've found. Plus, the memory that the throw routine is reading from is volatile, so if you try to read from the same addresses at some other time you'll get unrelated values. So throwboxes could only be implemented if there were a way to set breakpoints with Lua. (memory.registerexec())

Preliminary Fatal Fury series hitboxes

I have the hard part of the rbff1, rbffspec, rbff2 & garou hitbox code figured out. (Didn't examine the first four in the series yet.) It's totally different from KOF system. But there's a problem...

There's a four-byte pointer at 0x7A from the start of every character and projectile memory slot. The data for a box is packed into five-byte blocks at that pointer, and there are several boxes per pointer. Within each block, the second and third byte give the vertical distance from the object axis, and the fourth and fifth byte are horizontal.

Hitbox script index page

Here's a list of all the games that have working hitbox scripts. It's a nice public page so you can link it anywhere.

http://code.google.com/p/mame-rr/wiki/Hitboxes

A big commit brought all the scripts up to date.

Should have done this a long time ago. I guess this stuff could have been put on its own page from the beginning instead of with MAME-rr. In any case it's good that they are in a versioning system, so people can track changes and get updates if they want.

The KOF hitbox ID system

My theory that the function of a box depends on its ID byte turned out to be sort of correct. Unlike the Capcom hitboxes, where you can tell what a box does from its place in memory, in KOF a blue box can occupy the red slot. On the other hand an attack box outside of its usual position apparently does nothing.

In the first version of the script these were showing up as blue, but they can't be hit. (I guess this was the concern that Phoenix raised.)

Then I made them red because of they had the same IDs as known attacks, but they don't hit either.

They're gone now.

Consequences of this:

KOF throwboxes

After some more trace-crawling I found the throw boxes for kof96 through 2002. There's a slot for the grab area and another for the grabbable area near the end of an object's memory space. I made them yellow and white respectively, same as in prior scripts. Press hotkey 5 to show them. Failed throws that turn into normal attacks do show up this way.

It's worth pointing out that regular ground and air throws are direction + one-button, like SF2, but they take some time to come out. The direction isn't checked until two frames after pressing the button, and the stick must be held for at least two frames. This made it hard to nail down the exact time that the decision is made, and I ended up using Daimon's instant hcb,f+P to experiment instead.

kof94 hitboxes, autoguard boxes

Got kof94 added after some ramsearching. Same hitbox code, different address and offset arrangement.

---

Phoenix pointed out that some red boxes in kof2002 aren't for attacking but for automatically blocking.

After dealing with the problem of red boxes that are supposed to be blue, on a hunch I referred to the first byte of the attack box's block again. It seems that if it's 0xB, the box should autoguard. It's not limited to attack boxes. For example, the startup of Yashiro's f,d,df+C has an autoguard box that is otherwise the vulnerability area for his head. I made autoguards gray.

I'm thinking now that the function of any non-pushbox depends not on its position in memory but on the value of its first byte.