April 2012

This was another month spent trying to make it through each day.

---

March's banner was from Kirby 64: The Crystal Shards. As a mainline Kirby title, the gameplay is primarily platforming action, with abilities absorbed from enemies as weapons and puzzle-solving tools. K64 featured only seven, but they can be mixed in any combination of two, for a total of 35 special abilities.

Kirby was late in coming to the Nintendo 64, and K64 was not particularly ambitious for its release date of 2000—a year after Kirby's appearance in Super Smash Bros. The graphics are mostly 3D except for a few sprite-based enemies and objects, and the camera moves stereoscopically, but the game is controlled entirely in 2D and without analog support. (Compare that to Kirby Tilt 'n' Tumble, released the same year, which used a gravimeter built into the lowly Game Boy Color cart.)

K64 is pretty short. The level design, while aesthetically striking, tends to offer little challenge, and the tame difficulty level is offset by somewhat unresponsive controls. Though not among the best main series Kirby games, K64 nevertheless remains enjoyable in its own right. The graphics certainly are pretty, and a lot of effort was put into the cutscenes, which are pantomimed in the wordless Kirby-universe manner.

This game runs fine but shows some sprite errors in Project 64, the most popular N64 emulator. It's mostly better in mupen64plus, which is overall a healthier emulator (i.e., under active development, open source, cross-platform), but it's such a hassle to get running and configured it may not be worth it for Windows users. In other news, there has been recent N64 development in MESS, but games are not really playable for reasons of speed.

Comments

[XGargoyle]

Hello,

I have been investigating the Psikyo SH-2 hardware, and in particular the game Daraku Tenshi (Fallen Angels). I've been able to find the memory addresses for the collision boxes and dissected their system figuring out each byte (axis, width, height, box attributes...). I also found other interesting memory addresses such as disabling background layers.

I was wondering if you would be interested in this information for adding a new hitbox viewer to a game based on a different system than CPS or NeoGeo.

[dammit]

Yes. I'm interested in everything. But I can't be counted on to act in a timely manner with the other things I have going on.

You are welcome to dump the info here if you want, and I'll probably get around to it at some time. I suggest you do that, and additionally look for others to help out, and maybe try your hand at scripting yourself.

If anything comes up, you can keep us posted. If not, no big deal. I'd be happy to put anyone's working scripts on the googlecode page.

[XGargoyle]

Thanks for your reply! Yes, I totally understand your priorities and I never intended to force or demand you to code such script. My apologies if my previous message somehow gave that idea, and if it did, it could be due to English not being my first language.

I'll give a brief overview on how and why I found this information. I use a cheating tool called ArtMoney to obtain data from the game, which I then use to recreate the contents as accurate as possible for a fighting game engine called Mugen. Memory addresses in ArtMoney are using a different offset than in MAME, but the offset difference can be calculated and applied to find the real values in MAME.
Daraku Tenshi is rather obscure game, but its hidden features make it a pure gem. The game was rushed and unfinished, some of the Psikyo staff left the company and moved to SNK and brought there many designs and gameplay concepts that heavily influenced KOF'99. The game ROMs contain lots of scanned artworks, sprites for unfinished characters, and references to how the fully finished game should have been.
The game is emulated in both MAME and FBA, so the eventual existence of a hitbox viewer would be applicable to both systems.

Speaking to another fellow mugener, Felineki (the guy who figured out the Street Fighter 2 collision box system), he pointed me to your blog. Hence why I contacted you for the first time. Now, if you know other people or places which could be interested in my research, I'll be glad if you could tell me. The more exposure this information could have, the better odds there will be for someone taking a look at it and trying to create the script.

Certainly, there's no rush, and I'm happy enough to know I've provided my grain of sand to the emulation scene.

Unfortunately, I'm not good at coding, and even less experience with LUA. Gee, if I had such skills I would have done the script by myself ;)

Collision boxes in Daraku Tenshi use this structure (apologies for the length of the message):

The structure is based on 16 bytes containing information for 2 boxes. Explanation of each byte:
00: X Axis - Defines the X coordinate based on the character's axis
01: X Sign - Either set 00 or FF, defines if the coordinate above is a positive number (00) or a negative one (FF)
02: ?? - Unknown. Must always be set to 00 otherwise the box won't be activated. Couldn't figure out any other use for it.
03: Box attributes - This address defines the properties of the box. For vulnerability boxes, it defines how the character reacts when being hit (as if it's hit on the head, or the stomach, or being tripped down). For attack boxes, it defines the attack properties such as if it's a light or strong hit.
04: Height - Defined in pixels. A height of 10 pixels, means that the box is 20 pixels high.
05: Width - Same as above, but regarding the width of the box.
06: Y Axis - Defines the Y coordinate based on the character's axis
07: Y Sign - Either set 00 or FF, defines if the coordinate above is a positive number (00) or a negative one (FF)

Bytes 08 to 0F work in the same way as 00-07, but applied to a different box.

The 16-bytes structure above is repeated 4 times. Collision information for player 1 begins at 602DEA2 (in MAME).

Data for player 2 begins at 602E0A3, and uses the same format.

The structures use this pattern:
Structure 1: Attack box A, attack box B
Structure 2: Empty box, Vulnerability box A
Structure 3: Vulnerability box B, Vulnerability box C
Structure 4: Multibox?, Push box

Addresses before and after the boxes, are either all 00 or don't seem to be affected or influenced at all. It could be that they are eventually filled with additional data if they are actual projectile, throw, weak boxes, etc... but so far, I haven't found any particular moveset that modify these values.

"Empty box" is a coined term by me to define a zero-filled structure, which supposedly separates the attack boxes from the vulnerability ones. I've never seen this box being populated though.
"Multibox" is a weird box as sometimes it works as either an attack or throw box, and sometimes it's a vulnerabilty ones. Most of the time, there is no data for that box, and is only activated in some moves.

Now, some additional details on the system:

Data for the collision boxes are first loaded into memory and then "drawn" on the game on the next frame. This data remains in memory until new information is updated. This means that if a sprite only has one attack box, the data in attack box #2 could still contain info from a previous attack.

This makes me think that somewhere, there must be some addresses that define which boxes are active and which not, unfortunately I haven't found this information yet. These addresses will probably also define if the multibox is an attack or a vulnerability one.

Confirmation of my theory above, is that I found an address that could freeze the last attack box on screen. In other words, execute a kick, freeze the value on that address, and then you have an attack box stuck on screen which you could use to hit the enemy while walking forward or just idling. However, I haven't been able to completely figure out the whole scenario.

So, this will conclude my research on the collision box system for Daraku Tenshi. I have more notes and addresses which provide additional parameters and modify the game's engine. I'm not posting them yet, because either are completely unrelated to the collision system, or are not working 100% and need more research to completely assess their use. In any case, anyone interested in it feel free to ask and I'll provide what I've found.

Last but not least, I hope the material in this post could be useful. I'm not a coder, so perhaps the way I've documented it is not the best or the most suitable one from a coding perspective, so if you need any additional explanation or details or have any doubt in general, just let me know. As I said, I'm using ArtMoney for getting all this information, but it could be easily offset to MAME addresses. On the other way around, I can also test MAME addresses and place them into ArtMoney.

[Jedpossum]

Finally got sfex series to work on mame. I have sneaking suspicion that the character order on the mame cheats are wrong as the character select cheats only work on the character select screen and that byte actually changes.

[CWheezy]

Sorry about your life stuff dammit, hope it gets better soon.

Does your cps2 script work with karnov's revenge?

[dammit]

XGargoyle: Thanks for taking the time to lay out your findings. I can't promise I can find the time to cobble together a script but it's good to have this info out there.

As for connecting to like minded people... I've been looking for years, haven't found many at all. There are very few of us who do objective VG analysis and it makes it so hard to make friends and stay motivated. Wouldn't hurt to try posting around shoryuken.com, sonichurricane.com, tasvideos.org, tcrf.net, romhacking.net, and maybe other places. But the talent+interest density is low everywhere.

If you find more info and have nowhere else to put it, it's OK to just dump it in random comments. And if you can get those hidden goodies out of the ROM, you should post them to tcrf. Felineki has put some good Darkstalkers stuff up there.

jedpossum: The char select codes are wrong? If you can correct them, be sure to pass them along to mamecheat.co.uk.

CWheezy: Karnov's revenge? No, but that game would fit more in the neogeo script.

[Jedpossum]

Dammit: Some reason I could never sign up to mamecheat.co.uk. I'll keep trying as I have quite a few cheats to add for Vampire Savior, Breakers, and Breakers Revenge. I still need to make the second player for SFex series.

CHweezy: I'd say Karnov's Revenge/ Fighters History Dynamite would be better suited for its own script as the engine is very different then the other Neo Geo games. Plus on SRK I already have cheats that will give you access to the dev tools Hit Editor and PaTterN editor.

[XGargoyle]

Oops, I did a silly mistake on my previous explanation. Forgot that in the original game, values are byte swapped, but in Artmoney not, so the order I commented in my previous message is not the same in the original game. Taking a screenshot from the memory addresses in MAME, we have the following details:

http://xgargoyle.mgbr.net/daraku/daraku_box_info.png

Addresses in the blue square are for P1. Red ones are for P2.

The structure order is the same one:
Row 1: Attack box A, Attack box B
Row 2: Empty box, Vulnerability box A
Row 3: Vulnerability box B, Vulnerability box C
Row 4: Multibox?, Push box

However, values in the row are swapped, and the actual ones in the original game are:
(Box A attributes, Box A unknown, Box A Sign X, Box A Axis X) || (Box A Sign Y, Box A Axis Y, Box A Width, Box A Height) || (Box B attributes, Box B unknown, Box B Sign X, Box B Axis X) || (Box B Sign Y, Box B Axis Y, Box B Width, Box B Height)

I hope things would be more clear now. As I said, I'm not a coder, so perhaps someone more knowledgeable could rewrite my explanation to make it more understandable.

[dammit]

From what you've laid out it seems totally doable. (You already did the most of the work.) It's probably on par with 3rd strike in complexity.

[XGargoyle]

Hey, it's been a while since my last post, but I have been finally able to find the missing piece to completely understand the collision system in the game.

What I was missing was an address that defined which boxes were active and which not. Since information for the boxes stay in memory until being updated with new info, there had to be some place where the game defined the active boxes. Actually, the address was found in the early stages of this project, but it took me a long time to crack it and understand its behavior.

For P1, byte 602DE97 defines the active boxes. For P2 the address is 602E097.

Now, how do these values actually work? Easy, the given number (for example B8) must be converted into binary, giving us a string of 0s and 1s. The 1s indicate the active boxes and the 0s the disabled ones.

The box order is the following one:
Pushbox - Vulnerability box D - Vulnerability box C - Vulnerability box B - Vulnerability box A - Hitbox C - Hitbox B - Hitbox A

So, using our example above, B8 would result in 10111000, in other words: pushbox, Vuln.C, Vuln.B and Vuln.A being the only active boxes. 0-ed boxes may still contain data from previous moves, but they are not enabled.

Some additional comments, "vulnerability box D" is the box I previously called as "Multibox". It is in fact a vulnerability box that is placed sometimes within a hitbox, hence my confusion when I first found that data.

"Hitbox C" is what I previously referred to the "empty box". If we insert data into this box, it results in a fully working hit box. However, I've never seen it being populated throughout the game. It could be that the programmers never intended to use it, or that it's only used in a few moves that I haven't tested. In any case the box is functional so I though it would need to be added to an eventual driver, in case a particular move does use it.

And that's all. I believe there's nothing else that can be further analyzed regarding the collision system. There are no traces of additional boxes such as throw or weak ones used in other games, since the byte that defines the active boxes is only able to manage up to 8 boxes.

I could further investigate all the different hit attributes, but these don't affect the boxes itself, or their placement. They just tell the game how the character reacts when hitting or being hit. If anyone is interested, just let me know and I will compile a list.

In the same way, if anyone is interested in getting additional info or data from the game, let me know. I have tons of info and data values that perhaps may be interesting to somebody.

[miloyoyo]

Sounds like a lot of confusing stuff, but thank you for continuing to work on it!