Graphic addicts!

Megaman’s AI is roughly half done. Unlike the Sept demo, he now incorporates some of the iconic movements and animations that make a Megaman game, such as the pixel-forward step before a run, the little slide as he stops, even him sliding on ice. Doesn’t sound like much, but BASIC programming doesn’t make it easy. I haven’t re-implemented his shooting yet, but I hope to also work on all his projectiles and not just one really soon.

Getting much of these things out of the way (mainly all the bugs that were hidden but now fixed), I began testing the waters as to how many graphic blocks I can compress and cram into a single GRP. From the looks of it, having almost all the sprites is estimating to be just under 40Kbytes, roughly 10Kbyte short of filling an entire GRP. Just to give you an idea of the compression ratio, there are currently 3152 8×8 pixel blocks that are compressed. Uncompressed as 4-bit (16 color) blocks would take up 101KBytes. 2-bit (4 color) blocks would be half that, but most of the blocks are not 2-bit. Based on this, I believe I’ll be able to to stay within the 4 GRP at-a-time limit, but I won’t truly know until the project gets closer to finishing.

One last thing. This collection of sprite graphics is roughly equivalent to 31 QR codes (the Sept demo was 43 codes), so be weary, because this game is going to be huge.

Looks like a couple steps back, but it’s really many steps forward.

It seems I’m going by monthly updates as I attempt to get back into the progress I was at when I released the demo back in September 2012, but with assets rearranged, compressed, and overall easier to work with, especially with many changes to how assets are handled. Here’s a list of things that I have gotten done…

  1. Functions for loading and using graphics, palettes, tilesets, and sprites are all done (for the moment). They can now be used for numerous other functions, like levels and entities/objects.
  2. As of this moment, all assets not code-based are now stored in GRP files in a structured manner. This means graphics, palettes, animation data, etc are all stored there, some of which is compressed to reduce space. This will ultimately allow the entire game to then be packaged together (so no more scanning codes for multiple files, and no more extra files required, just the program).
  3. Dynamic allocation of assets loaded, like graphics, sprites, etc. This may not mean much to end-users, but it makes a lot of difference for me, especially if it means I can load an asset on demand rather than limited to loading at the beginning of a level, which is how it was handled before.

I am currently getting our dear hero Mega Man back back into the game, dealing with his AI and interacting with the levels, using the reworked functions I recently made. Do not feel distressed if you think I’ve taken many steps back from the September demo. To put it into perspective, the September demo was extremely restricted, and would not have let me do many of the things required to mirror the original game, which is why this re-working was necessary, and already allows much more flexibility in its current state.