LÖVE

First I drew every tile in my game with a separate call to draw. That wasn't a very clever way so I used spritebatches. I have the world separated into areas, each having its own spritebatch.

Now I want to draw animations instead of the tiles (grass wiggling in a breeze, water waving in a wave, trees treeing a breeze etc.). For all of these I will have some sequence of frames which I need to draw.
No due to my vast prior experience I think that drawing each one of these animations separately is a bad idea.

I have a few ideas how to achieve this:

1) Have each area now have multiple spritebatches which contain all animations. Say my grass needs 5 frames for its animation, the water needs 3, then I would have to have at least 15 (lowest common multiple of 3 and 5) spritebatches per area s.t. I can draw both animations, and these 15 spritebatches would just contain 3 full grass animations and 5 full water animations.

2) Have each area posses multiple sequences of spritebatches. One which only draws grass, one which only draws water. In the above example I would now have two sequences of spritebatches. One of length 5, only drawing all grass in the area, One of length 3, drawing all water in the area. I think this is nice since it decouples the two animations from each other. On the other hand this will increase the number of drawing calls, but I think this should still be manageable.

Is one of these two ideas the right one? Or would you do it completly differently?

Both of those solutions could work, most definitely, consider, however:

- Keep your current 1 tile-spritebatch per area,
- the image atlas used with it should have separate tiles vertically,
- and animation frames for the same tile horizontally.
This would be a simple arrangement, even though some empty space may remain due to tile animation lengths being different, which may be fine.

Then again, going one step further, if you'd need to define the frame count per tile anyway, you could also define additional parameters for the atlas image (like where a specific tile is located in the image; vertical and horizontal offsets in either tiles (if everything has the same dimensions) or pixels, along with how many frames a tile has. you'll also need the dimensions of the whole atlas too for wrap calculations), and doing so would mean you could squeeze everything in it in a way that doesn't leave any empty space in the image whatsoever.

Thank you for the fast answer
What do you mean with "1-tile" spritebatch? At the moment one spritebatch draws a lot of different tiles (it draws a full 32x32 rectangle which contains grass, water etc tiles)

And I don't fully understand your last paragraph. What I do at the moment is having a sprite_sheet with just having the tiles somewhere and a .json tile which gives all the information of where which tile is located etc., so that I can convert that information to quads easily. Is that what you mean?

1 (tile spritebatch) per area, not(1 tile) spritebatch per area; basically meant that you don't need to have more than 1 spritebatch per area.

As for the last paragraph, if you're using json for defining quads, then you can absolutely define animated tile frames there.

Ah ok thank you. But how do you mean that I don't have to have more than one spritebatch per area? My idea is to have say 3 spritebatches for the grass animation (which draw the grass stuff) and 5 for the water (which only draw water) and then per frame always draw one of the grass sprites and one of the water sprites so that it looks as if everything is animated.
How would I achieve that with only one spritebatch?

Let's go back to my first idea then, to illustrate it.

Suppose you have an atlas image that's built up like this: If the tiles are 32x32, then the image itself has dimensions 160x160.
You load the image into a spritebatch, and start adding sprites.

Then, you create one or two timers, depending on whether you want both grass and water to update frames at the same rate or not; you decrease them to 0 in love.update; if they reached it, you modify the relevant sprites in the batch with SpriteBatch:set (SB:add returns an ID, you probably should store those in tables, separated by type since the frame counts are different) by using another quad, that points to the next frame, and that will make the sprites animate.

Ah now I get it! Thanks for taking the time to explain. So what you say is that it is better to have one spritebatch which I modify instead of having multiple spritebatches which are modified not so often.
My idea was all the time to have a few spritebatches which all draw the screen in a different state and instead of modifying the spritebatches, just draw one of the different spritebatches at a different time. That was why I had such a hard time understanding you. Thanks!