The VG Resource

i couldn't revive the old rondo project thread

anyways yeah i did some animations where i tried to optimise tile usage as much as possible, here are gifs
[Image: HK4mtDl.gif]

and

and some new enemies and bosses as you can see

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)

please give crits erryone

edit: edited and made more skeleton anims
[Image: vXcASfo.gif]

(06-20-2015, 05:22 PM)Lexou Duck Wrote: [ -> ]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.

depending on what your trying to minimize the approach could change drastically,
if you were trying to minimize memory, pack your sprite as a stream of tiles, hypothetical situation of 24 x 24 sprite (3 tiles by 3 tiles), pack like so,

Code:
[XY][XY][XY][00][10][20][01]

[11][21][02][12][22][XY][XY]

[XY][XY][XY][XY][XY][XY][XY]

preferably frame after frame too, but the point being, getting your sprites tiles only requires, the offset and size.
this approach ofc lends itself to much larger sprites better than it does smaller, memory vs compute I guess,

Code:
for (var X; X < width; X++)

    for (var Y; Y < height; Y++)

        spriteTile[X, Y] = tiles[offset + X + (Y * width)];

ofc I have no clue what your working with so this is as rough as possible to let you do as you wish with it

welp i went and made it all

ill post the source for the TileSprite class i made on pastebin for y'all once i've commented it a bit more
its probably not very optimised, i'm working with several 3-layer inception arrays but i have no idea how to do that json stuff youre talking about pugg
but yeah it animates on its own, drawing all the tiles into one bitmapdata and it supports flipping and 4 rotations for any tile

so yeah from this
[Image: bcJVvtB.png]

i get this
[Image: 2dhVAp3.gif]

(plus it's already quite playable and all wouldja look at that)
(the gif lags but the game doesn't don't worry)

Neato. The JSON stuff was just for files that specify how to construct and animate frames, as opposed to hard-coding it. It seems to work for you though so if you're happy with it then it's fine.

It'd be cool to check out that code once you've commented it.

Lexou Duck

puggsoy

Bombshell93

Lexou Duck

puggsoy