What's this ??!! A wild RONDO has appeared !!!

[puggsoy]

also i tried to start programming this into haxe a bit
and well ive started trying to make my own tiled sprite animator for 8x8 nes sprites
and holy fuck this shit is complicated, and im sure whatever i could muster wouldnt really be optimized
(puggsoy if youre there help me)

Uh OK let's see. I've never done tile-based animations before but I've got some ideas.

So you load in all your tiles for an enemy, and you've got them numbered from 0 - 36 (considering the 37 tiles of the small skeleton). Let's say they're numbered in the order they are in your sheet, from left to right and then top to bottom. What I'd do is construct the frames for each enemy using these tiles. So for example, for that first frame you'd define it by listing the tiles its made of in something like this:

Code:

anim: walk
frame: 0
tiles: [0, 1, 10, 11, 20, 21, 28, 29]
xCoords: [0, 1, 0, 1, 0, 1, 0, 1]
yCoords: [0, 0, 1, 1, 2, 2, 3, 3]

I've put this in a format of a file (like JSON or just your own format) you would load and then parse. I don't really recommend hard-coding these in, it's possible but would just create gigantic classes and in the long run make your program binary much larger than it need be. Files loaded at runtime would be neater and also allow you to tweak stuff without recompiling.

The anim and frame would just be as identifiers. However it would still be best to construct the animations manually (i.e. stating the order of frames) so that you can use the same frame multiple times in a single animation.
Anyway, the tiles array states the tiles it's composed of, by number. The xCoords and yCoords tell you the corresponding coordinates of each tile within that frame. These aren't pixel coordinates but rather tile coordinates, hence (1, 1) would actually be (8, 8) in pixels. It just keeps things simple and ensures you won't get tiles overlapping or gaps between them (of course if your animations require this then you could allow it).

Exactly how you'd end up constructing and rendering these depends. One thing you could do is create a graphic object for each frame, like a BitmapData. On one hand it keeps stuff simple and means you load and construct once, on the other hand your memory's gonna be full of images, many of which will share tiles and sort of defeats the point of them in the first place.
The other thing you could do is have the engine manually render each frame from its individual tiles every time it needs to. That is, instead of constructing an image and rendering that, you just render the tiles directly in the positions they're supposed to go. This would probably save memory, but might be more processor intensive, I'm not sure. It could also introduce more opportunities for bugs (like individual tiles being rendered where they shouldn't be).
By the way, I just took a quick look and Flixel's FlxAtlas seems like it might be related to is. I've never touched atlases but they may be worth looking into.

As I said I've never done this before, so this is just a very rough generalisation of how I would go about it conceptually. Feel free to point out any flaws or extra ideas, it'd be good to flesh this out a bit better. I'm not sure how much trouble you'd have with the actual implementation either but I can try help if you have any issues.