No more pixel counting for a while

I finally finished manually correcting the shot placement for every possible player animation, so that the beam weapon bobs along with the player as he moves. It was a lot of work, but on the whole I’m convinced it was worthwhile. The weapon’s beam now follows the character’s movements in a way that looks convincingly organic. Have a look!

Near the end, you can also see a debug mode I created just for this purpose, where the frame number of the character’s current animation is drawn on top of his base image. Then I just had to manually tweak the shot placement for each frame of each animation, note the appropriate offset on a legal pad, and repeat until done. Certainly it’s tedious, but less error prone than trying to count the pixels in the raw animation images and quite a bit faster. And I’m now done!

That means I get to move on to the next secret feature of the game, which we will discuss more tomorrow.

3 thoughts on “No more pixel counting for a while

  1. Well done. You certainly got the offsets correct, as it’s hard locked to the barrel from what I saw in the video. You rotoscoped the player, didn’t you? I can’t specifically remember and may have assumed from the beginning. A great technique.

    This probably sounds like the ultimate horror right now, but if you also hard-coded the offsets to the center and the vector/orientation of other player segments (head, torso, back, gun/arms and boots), you could center and rotate textures on top of the player. Inventory items would have associated body parts and be immediately visible.

    For practice you could adjust the existing barrel offsets to make a gun texture overlay. Maybe use an existing variable for it’s direction? Contra guns are a good match with Super Metroid if well textured.

    • Yep, rotoscoped all the way! No way I could draw that animation so smoothly otherwise.

      Wow, what you are proposing makes me want to crawl into a corner and cry! Maybe I will have some renewed enthusiasm for character artwork in a few months.

      • Awesome. I love rotoscoping. Ever since Wing Commander II’s famous running from the briefing room to the fighters I was sold. 😉

        Fortunately I have an idea which may help with the otherwise entirely manual process of penning position offsets and angles. While it would require a little “up front” work, the rest would just go.

        Basically you would make a copy of all your player animation frames (as in copy/paste via your OS’s filesystem), then write a few “special” pixels to each frame of the copy. The pixels would be in pairs, one for the center of the body part and one for the target it was oriented toward.

        Let’s say the center pixel of the player’s head was written as RGB 255,0,0 and the target of the head was RGB 254,0,0. You’d write a pixel to each frame in the middle of the player’s head using RGB 255,0,0 and likewise a pixel for of where the head was looking/facing using RGB 254,0,0. You’d then create a separate utility program to analyze these frames pixel-by-pixel looking for the two colors. 255,0,0 would be recorded as the “center offset” for the head for that frame (flat file, database, whatever you use), and 254,0,0 would be stored as the target. You could then calculate and store the angle between the center and target pixels for use as the rotation for helmet gear textures.

        If red’s the theme for head calculations, green could be used for gun calculations (0,255/254,0), and so on.

        If this seems like too much work, the same program and logic could be used for enemies which were destroyed in pieces. Imagine a creature with a segmented exoskeleton, such as an insect or crustacean (or even mechanical/robotic enemies with armor). Initial damage could remove their “inventory items” first (armor, shells), exposing their inner flesh to further damage.

        If you just had a few animation frames you could do it manually, but I don’t see any other way when you have 100+.

Leave a Reply to Kevin Fishburne Cancel reply

Your email address will not be published. Required fields are marked *