LÖVE

Quads? interesting..

Positive07 wrote: That may be wasting too much (I mean, anim8 creates data needed to animate like all the assets in the grid in a table, and position, width... etc etc, you just need the image section), use a [wiki]Quad[/wiki] instead, you can create one with [wiki]love.graphics.newQuad[/wiki]

Ah, but you would be sacrificing code readability for some theoretical speed. Before the code didn't have to know that there were differences between animations and single quads. It could treat everything as an animation. Now you have to make at least 1 if somewhere to differentiate between animations and "stills".

Also take into account that depending on the situation, using a quad could be slower than using a single-frame animation. I know it's counter intuitive. Let me explain.

The time can be spent in two places: when creating an animation, and when using it (updating + drawing).

Updating an animation and then drawing it is very fast - almost always it's just an if and a draw call. It takes almost the same time as drawing a single quad. So let's examine creation time.

An animation is a table with the "main datapoints" (like frameWidth and frameHeight). Two of the attributes of this table are also tables: there is a table containing the "frame" (the result of doing g(1,1) ) and a table containing "frame durations" (essentially a table of numbers).

The main table and the table of frame durations are created really fast. The frames table can take time (creating each individual [wiki]Quad[/wiki] can take time). This is why every call to grid:getFrames() is memoized. The quads that are created once are not created again.

What this implies is that, if you create lots of 1-frame animations, that can be faster than creating lots of quads (because the animations memoize the quad creation by default).

Of course you could manually reuse the same quad again and again in the manual approach and that would be faster. But the code would be even more complex. Using a 1-frame animation really gives you a lot - do not dismiss it so quickly.

lex wrote:do I still use the 0.1?

The animation code does a bit less work if it doesn't "change frame", so for still animations it will be slightly better if you use a bigger number there - like 1 or 10 seconds. But the difference is so small that I doubt you will notice it (you might notice some percent points difference it if you animate thousands of objects simultaneously)

kikito wrote:-snip-

Oh!! Memoizing, yeah then you have a win there, also about checking if is an animation or not, you are totally right, it is better if you dont have to differentiate

PS: It would be awesome if anim8 could tell that there is only one frame in the animation and dont animate at all (just a nice feature...). Or maybe another API for still images? Dont know

kikito
This is perfectly valid to just display a single image? from the big picture right? and not as animation!
I am trying to keep up also I will use Quads+anim8 I think both will give me what I want..
BTW..you made the anim8?

Anim8 uses quads internally to build up the individual frames.

The rule I would use is: If you are doing a character (player, enemy, bullet, explosions), use an animation (even if some of the animations only have one frame).

If you are doing static scenery (floors, walls, etc) use quads. (Later you might want to group those quads in a canvas to save up some draw calls, but don't start there). Of course if you want animated scenery (like water waves, or grass moved by wind) use an animation, not a quad for that.

I confirm I made anim8.