Wednesday, July 09, 2008

C64 Framework progress

I'm doing pretty well with this so far and have managed to get 30 sprites being multiplexed using 7 hardware sprites. I usually prefer to leave one sprite for the player so that theres never any danger of them glitching or tearing, and also that being sprite one they will always appear over the top of the rest of the sprites. However if you wanted to multiplex all the hardware sprites, it should be pretty easy to modify things to do so. I've ended up putting both sorts in just in case theres a case where the old one wins out which may be possible in some rare instances, but mostly I expect folk to use the new one. I might also put in Dan's one from Armalyte as it has a differnt range as well and may provide yet another option given a games unique circumstanstances.

If no one gives anything else they'd really like to see added, then I'll simply add a single sprite being controlled by a joystick and that'll be it really. What's here is a good head start for any new game, as a solid multiplexor is always first on the list of things to write. Thats not to say this is the best option for every game mind. In Ballistix (and also Morpheus if memory serves), I used fixed IRQ bands and a sprite was inserted into a band the "Y" coordinate fell into. This has the added advantage that the SORT is virtualy instant as its basically a bucket sort. Take the Y coordinate, shift it down a bit, and store it at the end of the bucket list. Easy. However this multiplexor is very flexible and will allow for large joined sprites to move in sync which a fixed banded one wouldn't.

I will at somepoint do this for the Plus4 as well, but I'll need to untangle the software sprite system from XeO3 first, and that'll take time. I also don't expect people to use 30 sprites either, but its what this can manage when pushed to the limit - unless your on a super CPU of course, in which case you can use it incredibly high. I will also at somepoint release a proper SuperCPU framework but I suspect theres less demand for that since theres only a couple of folk that even HAVE one!

5 comments:

Simon said...

I'm a bit of a noob when it comes to prgoramming, but I have to say this is really fricking cool!

simon said...

In fact, I'm also a bit of a noob when it comes to just spelling the word. :/

Mike said...

Well I've no idea if anyone will use it in anger, but even if someone looks at it and gets ideas then I guess its served its purpose.

When you get right down to it, its the framework I'll be using in the future and I'm just letting others use it as well... :)

Vladimir Janković said...

Nice thing to do Mike! :)

Thank you in advance!

Do you have some sort of system for animation of sprites?

Or is it simple and crude engine?

Mike said...

No I haven't done any animation system as they are generally very simple. Given a list of frames and a delay, your best to just tick through the list...

Anim1: db 2, 1,2,3,4,3,2,-1

Something like this would mean a 2 frame delay, then use the bytes following as frames until you hit a -1 at which point reset the frame to 0. Easy :)