Actually making progress: tricked out metasprite routine

[psycopathicteen]

...and I broke it. It feels like I'm trying to pull out a table cloth from under the dishes. Maybe I'll try giving each object a register pointing to it's index on the list so it doesn't have to keep looking into it's metasprite data for it, and designate frame 0 as no frame. I guess you can say I should've had the frame number point to the metasprite data, and not the other way around.

[Stef]

Maybe I'll try giving each object a register pointing to it's index on the list so it doesn't have to keep looking into it's metasprite data for it

A bit related as this is exactly what i'm doing in my sprite engine :p

So 2 months ago a new version of my SGDK library for MD, ok it's for Megadrive but i think the Sprite Engine part can be interesting for you or at least give you some ideas
In this release i almost entirely rewrote it as the old implementation was too slow to be usable in real game condition.
The new implementation is faster but still done 100% in C so not blazing fast... I plan to eventually convert to assembly critical parts when code will be mature enough (it still need some polishes and probably a bit of bug fixes here and there).

The core sprite engine implementation is here :
https://github.com/Stephane-D/SGDK/blob ... rite_eng.c

But it relies also on the VDP sprite unit (low level sprite access) and VRAM unit (Video memory management).

The Sprite engine basically give you high level Sprite capabilities, handling meta sprite, vram and hardware sprite allocation for you.
It also handle automatic sprite visibility to limit the sprite per scanline usage (on MD even if the sprite is outside the horizontal screen range it will consume the scanline sprite slot). All these features cost CPU time and hopefully you can disable / enable them depending your case (you can for instance have automatic hardware sprite allocation while having manual VRAM allocation).

I know the code is complex, probably too much for your case as i intended to have something really generic, flexible and still "fast enough" for SGDK. Still i believe you can grab some ideas from the implementation and the structures

[psycopathicteen]

Got it to work. Might as well get rid of the special cases like explosions and fireballs, and instead, animate them like everything else in the game, now that there's no limit a generally animated can be copied on-screen.

[Drew Sebastino]

Good job! It's funny, because explosions are the main reason I want to use the system I am. It kind of works that what I'm doing currently uses 8x8 and 16x16 sized sprites, because it's easier, and if people ever figure out how to multiplex sprites on the SNES, I'm definitely doing that.

[psycopathicteen]

The downside is I have to fix slowdown again.

[psycopathicteen]

I got the VRAM linked list working. Yeay!, and it only a couple minutes at midnight when the house was quiet, plus a couple minutes between church and work.

Now the next thing I want to improve is animation frame rate consistancy. Certain moves look choppy when there is a multijointed bosses on-screen because of the rotating DMA priorities. I'll redesign it so the main character always has priority over other objects on-screen when it comes to DMA updates so the player's animation always has perfect timing.

[Drew Sebastino]

I didn't know you'd have rotating DMA priorities, I'd have thought you'd have it to where a certain animation frame would always want to be updated. The only problem is that this could cause you to try to update more than you can in one frame, which in that case, I'm just going to have black spill over the screen.