I added Battle Circuit to the beat 'em up script and made improvements to the hitbox handling of Punisher and Cadillacs & Dinosaurs.
Battle Circuit is the last of the CPS beatemups (1997) and builds on the legacy of its predecessors. There's the spaceman funk vibe from Captain Commando, the high speed, grappling and juggle combos from AvsP, and the buyable powerups from D&D. With the ability to buy new moves and five characters to pick from, the differentiation is pretty extreme and satisfying to any play style. The trade off is a stronger emphasis on memorization, but at the late date that the game was released, players needed more than a Final Fight clone anyway.
Battle Circuit was never ported to console and there's no USA version, which pretty much makes it emu-bait. Adding it to the hitbox script was pretty straightforward. I'm getting to believe that newer games are easier to deal with than older games, which would have been more experimental to the developers and less standardized in their programming.
In some of the already added games, there were some boxes showing up when they shouldn't, such as the barrels in Punisher always having a red box even when they are just sitting there. I went in and fixed a number of these. It's usually not hard to address these, but it gets really time consuming to confirm that fixing a false positive doesn't cause a false negative somewhere else.
This kind of thing is much less of a problem with fighting game scripts because I can run though all the likely problem cases in my head and then quickly set up a versus match to test them. Not so easy in a beatemup, where not only can you not control the enemies, but it can take some effort to get to the end of stages and check on the bosses. Savestates help.
There were also two interesting cases of missing boxes in the previous script version.
In C&D, everybody had proper boxes except for the raptor and T-rex type dinosaurs. The reason they are different is they're big and have two vulnerability boxes. (So far all beatemups I've studied have had just one per object. Some big targets, like Punisher's Guardroid, get around the limitation by having multiple objects.) It would have been less work for both of us if the developers had added another vulnerability ID byte to everyone's data and just left it zero for most of them. Instead, a different block of code is run for the dinosaur blueboxes. For each vulnerability ID, there's data for two boxes back to back, although some animation frames still have only one. Whether there's one or two is determined by the first block of box data.
...Why is the door so huge? Is it Guardroid's log cabin?
The laser attacks of the Guardroid and Kingpin bosses in Punisher were missing correct redboxes. The attacks behave in a pretty unboxlike manner: they slope downward from the point of origin and if they touch you on the ground or in the air, you get burned. A trace revealed that they execute different code from normal hitboxes, and the box data in ROM looked unusual as well, with a small positive number followed by two negative numbers. The trace showed that the first number was an iterator for a dbra (loop) routine and the negatives were modifying an X and Y offset from the laser's origin on each iteration.
There's a point where I have to stop trying to read the assembly because I can't comprehend it precisely enough. Between the hexadecimal math and the opcodes I only half understand and trying to remember what register contains what information, it makes it too hard for me to grasp everything analytically. So I take what I think is going on and tell the Lua to make it happen, then test if it makes sense. That's what happened here. I knew the code is scanning along the length of the laser to detect a target and worked from there. The Lua expects to draw a fixed number of boxes per object, but the number of laser boxes (the iterator count) is indeterminate, so some modification for this special case was required. It skips the usual routine and draws the stair step pattern you see above.
Posted by: |