Sprite sequence / sprite sheets

I am looking to do a simple animation sequence using a series of imported PNGs. At this point, I can only see one (practical) way of getting my PNGs into Codea, namely importing them through the sprite() function. Given that I have 10 animation states for a single sprite, this means (as far as I can tell) creating 10 sprite instances, and maybe playing a game of hiding the unused ones off screen.

This is crazy*, so there must be another way that I have yet to discover. What is the best practice here? My images are around 320x320. Can I create a sprite sheet and show a viewport of that sheet? Sorry if there’s already a tutorial out there that covers this; if there is, just kindly point me in that direction.

  • well, unsustainable. Imagine a game with a 100 sprites (not a very large number) at 10 states each, that means Codea is tracking 1000 sprites per update. I don’t know Codea’s performance limitations, but I would expect it to choke, or at least slow down its frame rate considerably.

So, I’m hung up on the idea that I need to initialize all these sprites at once because that’s how the current editor wants you to import them - you have to type sprite() into the editor to be able to import the sprite, so that’s a logical assumption.

My guess is that I can use the editor, type sprite(), then load in ALL my sprites from my Photo Gallery, and then just delete that bogus sprite() call, and then programmatically call the sprite in as needed. I’m assuming here that sprites do not persist into the next draw() phase, and I’m also making an assumption that the creation of a sprite instance does not incur a lot of overhead, unlike other graphical programming environments - if I’m wrong, then this approach will really skunk up the update loop.

I don’t understand the reasoning behind the way sprites are currently imported into the project library. If there were a Manage Project Assets UI that handled the import etc independently of any coding in the Editor, that would be a vast improvement I believe.

Hi @TomAuger, I think its time for you to meet our little friend the mesh… If you are just prototyping, I think leave it sprites for now, but sprites do get slow when there are many… You could save your sprites as a variable or put them in a table using readImage (look in the documentation). I don’t know why, but you are assuming you have to call every sprite every frame… Dropbox is a nifty way of importing photos. And finally, just look on previous posts on the forum!

Hi @TomAuger - here is a simple example I put together for animating from a sprite sheet (using meshes as @Jordan suggests)


Here’s another thread with a comparison between sprites and meshes


Also @toadkick has put together stuff for importing from TexturePacker - see this thread


Awesome! Thanks to you both for the hints. I had already read about meshes and was beginning to start looking into that.

But, if you use meshes for your 2D animation work, is there any chance of losing that 1 - 1 pixel mapping? Coming from other 3d environments, when you map a texture onto a surface, there is often some interpolation or mip-mapping that goes on, usually to excellent effect in 3D shading, but not what you would want if you’re hand-drawing your 2D artwork on a pixel-by-pixel basis.

Is this the case in Codea?

Codea’s sprites are essentially rendered using meshes anyway — it’s just that the sprite command conveniently handles all the necessary setup for you (which adds a lot of per-sprite overhead).

As long as your mesh sizes are 1:1 with your texture sizes you will get no interpolation (unless you scale() or zoom the entire viewport, changing it from the default orthographic projection).