How to animate many squares most efficiently

totebo

Calm your boots John, this is exactly what I've done.

Single mesh, and only setVertex to move the squares. To be able to use easing I use MovieClip to do that part, but using a custom attribute for the tween so it uses setVertex instead. Code attached. Turns out GTween is faster that MovieClip in this case.

Just setting position is a lot faster, so it's likely GTweeen and MovieClip causing the slowdown. Maybe there is another way of using the easing library that is faster?

Edit: Just tested the same code on an iOS device, where it is slower than with many Shapes! To be continued...

john26

I think you have to abandon MovieClip and GTween in this case. You cannot consider the individual squares as "objects", the entire mesh is an object.

Here is an update of the code above that shows a simple animation. It's like what you did originally but just linear interpolation. (If you want to use the inOutSine etc just look in the easing.lua file that comes with GTween.)

function rgb(r,g,b) return math.floor(r)*65536+math.floor(g)*256+math.floor(b) end   local size=50 local frame=0 local xtarget={} local ytarget={} local mesh=Mesh.new()   function update()   if moving then   for i=1,1000 do local x=xtarget[i]*frame/200 local y=ytarget[i]*frame/200 local vstart=(i-1)*4   mesh:setVertex(vstart+1,x+0,y+0) mesh:setVertex(vstart+2,x+size,y+0) mesh:setVertex(vstart+3,x+size,y+size) mesh:setVertex(vstart+4,x+0,y+size) end   frame=frame+1   if (frame==200) then moving=false print ("finished moving") end end   end   for i=1,1000 do local vstart=(i-1)*4 local istart=(i-1)*6   xtarget[i] = math.random(100) ytarget[i] = math.random(100)   local x,y=0,0   mesh:setVertex(vstart+1,x+0,y+0) mesh:setVertex(vstart+2,x+size,y+0) mesh:setVertex(vstart+3,x+size,y+size) mesh:setVertex(vstart+4,x+0,y+size)   local r = math.random(255) local g = math.random(255) local b = math.random(255) local a = math.random()   local hexcol=rgb(r,g,b)   mesh:setColor(vstart+1,hexcol,a) mesh:setColor(vstart+2,hexcol,a) mesh:setColor(vstart+3,hexcol,a) mesh:setColor(vstart+4,hexcol,a)   mesh:setIndex(istart+1,vstart+1) mesh:setIndex(istart+2,vstart+2) mesh:setIndex(istart+3,vstart+3) mesh:setIndex(istart+4,vstart+1) mesh:setIndex(istart+5,vstart+3) mesh:setIndex(istart+6,vstart+4) end   stage:addChild(mesh) mesh:setY(100)   -- Mem and fps local sceneDebug = SceneDebug.new() sceneDebug:addEventListener( Event.ENTER_FRAME, sceneDebug.update, sceneDebug ) stage:addChild( sceneDebug )   moving=true stage:addEventListener(Event.ENTER_FRAME,update)

Note, no MovieClip or GTween and it runs at 60 FPS.

totebo

Wow, this is a lot faster. I think you're right; inheriting from Sprite and/or creating a GTween/MovieClip for each square seems to slow things down a lot. Thanks a lot!

totebo

I've managed to keep the speed (thanks John) and still keep things OOP. Now I'm down to the last bit, to animate it with a nice easing.

Any idea how I would replace:

local x=xtarget[i]*frame/200 local y=ytarget[i]*frame/200

With an easing from easing.lua? I've looked at easing.lua, but I haven't figured out how to actually use the easing equations in it.

john26

I think this

local x=xtarget[i]*easing.inBack(frame/200)

And the same for other easings. You need to add easing.lua to your project. This assumes you want it to complete after 200 frames.

This amount of maths in Lua may slow things down again, in which case LuaJIT would be better since it compiles the Lua code. But I don't think you are actually using as many as 1000 squares in the real game...?

Some of the easing functions use math.sin etc and, as @SinisterSoft says, it may be better to replace this with a local sine function. At the top of easing.lua you can put

local sin=math.sin

etc and then just use "sin" instead of "math.sin". Might make a difference...

totebo

That works perfectly! And yes, making repeated methods local makes a lot of sense. This is awesome, and so fast.

totebo

Guys, this is worth repeating:

local sin=math.sin

This trick speeds up EVERYTHING used more than once, not just methods. I localised all "self." variables and methods used more than once when moving the squares each frame and it increased fps by 5-10 (!). Genius.

SinisterSoft

Told ya! ;p

SinisterSoft

you should also do it for things like...

for loop=1,#monsters do local x=monsters[loop].x local y=monsters[loop].y

so it becomes...

for loop=1,#monsters do local monster=monsters[loop] local x=monster.x local y=monster.y

totebo

What is the "correct" way be to remove vertices? I do this, which makes it 0x0 pixels, but there is probably a better way, that releases the memory?

mesh.setVertex(1,0,0) mesh.setVertex(2,0,0) mesh.setVertex(3,0,0) mesh.setVertex(4,0,0)

totebo

How do textures work with a Mesh? Instead of squares is it possible to use different textures?

Also still looking for the answer to the question above.

totebo

Back to the squares! With the 2016-06 release I've had the pleasure to revisit drawing squares, with the addition of Pixel and Particles. In my tests Pixel is marginally faster than Mesh (not much in it), but Particles is miles ahead of Mesh - on some devices.

I've used the same test as above, with 1,000 particles with a 64x64 Texture. For animation I've used the quite brilliant setParticleSpeed. The results:

iPad Mini Retina: 60 fps (in fact, I can add up to 3,000 particles without a slowdown)
iPhone 5: 12fps
iPod touch 5th generation: 4ps

On iPad Mini the squares look perfect and it runs fantastically. On iPhone5 and iPod touch, apart from the speed difference, the squares are jagged and appear to be leaning slightly. Any ideas why this could be?

I've attached the Gideros project to this post.

antix

Nice. When I finally get round to installing the new version I will try this on my Pixel C and report back

SinisterSoft

It's early days for particles. I'm sure that @hgy29 will appreciate any feedback or ideas you may have.

SinisterSoft

I personally think that adding a way to have a different texture x,y,w,h within the same 'master' texture would be a good idea.

hgy29

Yes, thanks for the feedback! Anthony discovered that particles rendering is not consistent across devices (GL_POINT primitive implementation is not that well defined), so to overcome this I'll have to change the way I am rendering them, possibly less efficiently...

antix

@hgy29 I haven't installed the latest Gideros yet but how do a bunch of particles compare against a pool of sprites? I've found pooled sprites are terribly good.

SinisterSoft

Particles should be much faster as they are all the same draw command as far as I know.

hgy29

@antix, yes they should be faster because pooling is done at C level and as Anthony said, all particles are sent to the GPU in a single draw call

antix

Thanks. I also think it would be good to be able to use like texture regions inside a larger texture Atlas like @Sinistersoft said

totebo

Yeah on the iPad Mini straight up particles just FLY. Since I'm partial to square particles, however, I have to use a texture which seems to slow things down a lot.

SinisterSoft

@antix I've been chatting with @hgy29 in a pm and it looks like that is part of the plan.

antix

@SinisterSoft groovy. I'll not bother upgrading my own particle system any more then