Hi, again…

Sorry im filling this forum with stupid questions…
But How do you use a spritesheet?
Again im really sorry for this question.

Hi Jesse.
I think that , right now there is no support for spritesheets (sprite animation), you need to write a class, which use the readImage(“Documents:imageSpriteSheet”) function then create a mesh(), and add a rect to it with mesh:setRect(), then adjust the correct position and size of the image for the animation with mesh:setRectTexture().

There is an example here:

@juaxix Thanks for saying, and how do you use a tilesheet?

It is the same thing, you can reuse the code for tilesheet in the RPG creator
in this post, then add spritesheet animation properties, like frames, smoothing, and other parameters.

@juaxix Thanks!

You can also use the excellent TexturePacker exporters from toadkick, it is a great tool and covers everything, from creating the Spritesheets to using single sprites in your project:

@derhannes thanks !! i will look in to it later.

@Jessevanderheide - I’m assuming you want to know how to do this yourself. A spritesheet is just an image full of other images.

You need to figure out the x,y positions where each image starts and stops. Then, when you run the program, you open the spritesheet as an image, and then copy each of the pictures into its own image (there is a copy command that let’s you copy part of an image to another image). You do all this just once, in setup.

Now you have all the images separated, and can use them in your game

@Ignatz what exactly is the copy command? Never heard of it.

Doesn’t copying each sprite in a sprite sheet into it’s own image kind of defeat the purpose? :smiley:

If your mesh is set up properly, it should be as simple as using setRectTex to set the texture coordinates within the spritesheet for the required image.

Its easy to write a class that does this, especially if its and ordered grid of x_rows by y_columns - a bit more complicated if you have arbitrary placement of images within the sheet - but not impossible.

Tools like TexturePacker will often give you the option of laying sprites or images out as a grid, or for efficiency, can use some sort of algorithm to fit (or ‘pack’) a range different sized images within a square spritesheet. As well as the sheet, they’ll then export you a list of these texture coordinates that you can use in your code - although you’ll generally have to write your own routines to interpret these.

@andymac3d: I’ve done exactly that :slight_smile: @derhannes posted a link to
The discussion above. I wrote exporters for TexturePacker, as well as the SpriteBatch class to display sprites using the generated sprite sheet and data.

Honestly though, now that I think about it, recent improvements to Codea probably make “regular” sprite rendering more efficient than SpriteBatch + a sprite sheet. It may not even be worth the trouble.

@toadkick - was thinking the same thing. Originally way back in the aeons of Codea history ( i.e. a year or so ago!) the only way to get any degree of performance with more than a few dozen sprites was to uses meshes, sprite sheets etc. With the new sprite-batching updates - much less of an issue, although haven’t done any real comparison tests to see how these compare.

I guess spritesheets are still an ‘efficient’ way of storing multiple images without trying to manage lots of individual files which gets quite cumbersome on large projects.

@Saurabh - look in the docs for copy, eg


Copies the rect from x,y of img1, with width w, height h, to a new img2

@Toadkick - the purpose of a spritesheet is mainly to avoid clutter by combining images such as animation sequences.

You don’t have to read all the sub images into separate images when you start up. In fact, because meshes can only have one texture, setting a whole spritesheet as the texture allows you to use any of the sub images in that mesh by carefully setting the texture settings of each item in the mesh, to the sub image you want

Well, I think the main purposes of using a sprite sheet are a) you can eliminate OpenGL draw calls by batch drawing your sprites, and b) you reduce wasted texture video memory by packing a bunch of sprites into 1 texture, and loading that texture, rather than tons of individual textures that usually contain transparent pixels that take up video memory and aren’t seen anyway.

I see your point about aiding with animation, which is valid, but that’s really more of a side effect than the purpose, due to how much of a pain it is to import a ton of images into Codea for an animation (not to mention the fact that there’s really no good project-specific asset management strategy in Codea yet either) vs. just 1 large image that contains most or all of your sprites.

Thanks for the help!! I really like how nice everyone is around here :slight_smile: