Graphic addicts!

Posted on by
10

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.

Posted on by
1

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.

Work on MM2PTC is picking up.

Posted on by
1

There are many hurdles that I have to overcome with this project, and I have overcome some of them. Dealing with compressed data, trying to find faster ways to process information going all over the place, etc etc. One would think that with all this that I had to basically restart the project from scratch. You’d be right in that regard to an extent, but it is more of starting with a blank canvas, and taking pieces of what I already made, one-by-one, and redoing them to better handle their tasks rather than toss everything I’ve done and start anew. Also takes much less time to work with what I already have and add them back one-by-one than to have it all in my face at once. A lot less stressful too.

This last hurdle I’m working on involves sprites. From what I had in the demo, they are probably the most process-intensive part of the game other than AI, because every single sprite has an animation, and each animation has to be updated each frame. PEtit Computer has some sprite animation functions built in, but unfortunately, they are very “basic”, excuse the pun, and I need something more workable. If I were using a programming language that dealt with compiling, this would be no problem, but this is an interpreter, and doing something as simple as VARIABLE=1 takes far more processing time than one would think. I’m currently getting good results with what I have now, displaying 9 sprites, each having 2 parts to them, so technically, 18 hardware sprites. I may yet use the built-in animation functions, but it will be for only those sprites that best use them, and everything else will use my current method. No AI yet, so once I get to that, I can then compare it against the demo, which began slowdown with only about 6-7 sprites on-screen.

Compression and redesigning

Posted on by
6

Since my last post, I have continued working on sprite compression, making some programs to handle organizing and formatting of sprite rips, which will allow me to compile not just the compressed graphic data, but also some of the animation data for each ‘object’, so the only real BASIC code I’ll have to deal with is the AI for each one. I know many people are wanting to see results now after being left in the dark months after the demo was released, but I have none to offer atm.

Sprite work is not the only thing I have been working on. I have also been thinking of ways to streamline much of the code because the demo showed at least one thing. It was reaching the processing limit even when not much was happening. So, I’m having to rethink how things are done, and get to redesigning. For the moment, I’m looking into a faster method for background tile updating. Nothing to show yet, but unless my design is flawed, the number of calculations to update should be reduced significantly. Less time to handle one job means more time for other jobs.

Still kicking….

Posted on by
6

The holidays are over, and I’m trying to get back into the groove of programming this game. For one thing, I have been thinking about how I was going to handle graphic storage. Obviously the 8 SPR slots were not enough, so I had thought about going with GRPs and copying into SPR when needed. Turns out that wasn’t going to be enough either since I also I have to deal with storing the levels themselves. My plan from that point was to either make separate external GRPs that got loaded, and then load the individual sprites from there, or reformat all the sprites again to become 2-bit like they are on the NES (as opposed to 4-bit PTC is forced to use) and see if that would do it. The first choice would have gone against my plan for a single packaged game, and the second choice would have require a lot of extra work, as I’d have to rip and construct everything by hand, and then deal with sprites that used more than 1 palette slot. But then my brain juices began churning…

All these options had one thing in common. They were all uncompressed graphics that I would be dealing with. So, I got to work on a compressed format, similar to RLE (Run Length Encoding), but with a few options, and I think I concocted a few, one for 3-bit, and one for 2-bit. I couldn’t really tell you how much space I’d save with this overall, as it all depends on the complexity of the sprites, but examining the ‘Met’ sprite frame below, which at 32×16 pixels would be 256 bytes at 4-bit within PTC (or 128 bytes at the original 2-bit format) is reduced to 80 bytes with a combination of my 2-bit and 3-bit compression algorithms. So, a reduction of 37% from 2-bit? I think this will be worthwhile, especially since my decompression algorithms for these sprites may actually be faster than copying them uncompressed from GRP files (as they can only be handled one byte at a time).

met

Sorry for missing updates

Posted on by
7

I had been tied up with holiday business that I have barely been able to touch the MM2 PTC project for the past 2 weeks, and I don’t expect that I’ll have enough of a break to really dig deep into development until afterwards. I still am doing some here and there, but not enough that I can cut into a big chunk of it.

Some complications…

Posted on by
1

So, I compiled all the sprites together to get them ready for color matching, and made an unfortunate discovery. My plan was to store them all in the 8 SPR slots available, but it looks like I am a couple of slots over the limit. This means I’m going to have to change my design a bit. I’ll most likely do what I did with audio and move sprites to a GRP section. The common sprites (like Megaman, weapons, effects and items) will likely stay where they are in permanent SPR slots (therefore, no loading for them) while the rest get shifted over and will be loaded on request. I’ll continue updating my progress.

MM2 PTC Report – 11/19/12

Posted on by
2

So, the audio player was released this past week, marking the end of work on the audio that will be used for MM2 PTC. So, what’s next?

The next thing that is being worked on are the graphics. Unlike the music, which I had to manually create, the tilesets and sprites for the game are far more accessible because many people have already ripped them. While this makes my job easier, there is more to it than simply reusing what is already made. I cannot simply throw them into Petit Computer, and expect them to operate correctly. The sprites alone vary with size, most not even being aligned by a power of 2 (ex. 16×16, 32×8), so I have to organize them, and split up the ones that are of oddball sizes to use less sprite space as they currently use, with stitching them together within the program when I get to that point.

Another problem is use of palettes. The rips I’ve obtained are not saved with palette information, or are improperly assigned. This part alone will likely take up most of the time with graphics, as I’ll have to extract the unique palette combinations, and then edit the tilesets/sprites to use the palettes properly.

MM2 PTC Audio Player v2

Posted on by
2

I got done with the sound effects much sooner than anticipated, so I spent the later part of today integrating them into the same GRP file that the music was written to, and incorporated the new GRP file into an updated version of my Audio player.

Update is available in the MM2 PTC Files section as the original was, which was replaced. If you don’t see 25 codes, or it seems like a mixup of codes ranging to 22 and 25, either refresh your browser, or clear your browser’s cache.