How to animate many squares most efficiently

totebo · November 2015

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 · November 2015

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 · November 2015

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 · November 2015

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 · November 2015

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 · November 2015

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

totebo · November 2015

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 · November 2015

Told ya! ;p

SinisterSoft · November 2015

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 · November 2015

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 · December 2015

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 · July 2016

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 · July 2016

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

SinisterSoft · July 2016

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

SinisterSoft · July 2016

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 · July 2016

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 · July 2016

@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 · July 2016

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

hgy29 · July 2016

@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 · July 2016

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 · July 2016

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 · July 2016

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

antix · July 2016

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

Howdy, Stranger!

Categories

In this Discussion

Top Posters

How to animate many squares most efficiently

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

How to animate many squares most efficiently

Comments