Hi all,
I am looking for a better way of moving a lot of little objects then transition.to. I am trying to create a firework effect that I have working perfectly with transition.to, however the transition.to is to memory heavy and is causing way to much text mem usage. Does anyone have any suggestions?
Thanks,
Chris [import]uid: 126017 topic_id: 31073 reply_id: 331073[/import]
particle candy addon.
Do you use imagesheets?
What does transition.to have to do with texture memory? 10 images is 10 images.
If you use a lot of images try using imagesheets. Those handle memory better. [import]uid: 100901 topic_id: 31073 reply_id: 124309[/import]
Hey Jannie,
Sorry for the confusion I didn’t mean text memory I just meant memory usage. I don’t think using image sheets would help with this. The firework effect I am creating calls about 100 small 6 pixel by 6 pixel images that spread out in a random effect looking very similar to a firework. However the transition.to that I am using to create this random scatter effect is taking way to much memory usage. I will check out particle candy, but do you have any other suggestions?
Thanks,
Chris Brasino [import]uid: 126017 topic_id: 31073 reply_id: 124381[/import]
Use enterFrame, and have 1 update transition all objects.
local updateFireWorks = nil
updateFireWorks = function()
--Do Stuff here
if done then
Runtime:removeEventListener('enterFrame', updateFireWorks)
end
end
Runtime:addEventListener('enterFrame', updateFireWorks) Just make sure updateFireWorks has a reference to all your particles. [import]uid: 134101 topic_id: 31073 reply_id: 124383[/import]
Hi Ntero,
I’m not sure that would help. The issue is that I am using so many transitions in order to create this effect. I could be wrong but here is my code showing what I am doing. Hopefully this will help reveal the problem I am talking about.
Thanks,
Chris Brasino
[lua] local sqrt = math.sqrt
local mRand = math.random;
local abs = math.abs;
local redBalls = {}
for i = 1, 102 do
redBalls[i] = display.newImageRect(“images/fireworks/redBall.png”, 6, 6);
redBalls[i].x = 160; redBalls[i].y = 160;
redBalls[i].alpha = 0;
end
local square = function(v)
for i = 1, 102 do
redBalls[i].x = 160; redBalls[i].y = 160;
redBalls[i].alpha = 1;
end
for i = 1, 11 do
local saved1 = (i - 1) * 5
local saved2 = sqrt(50^2 - saved1^2)
transition.to(redBalls[i], {time = 1000, x = redBalls[i].x - saved2 + mRand(-3, 3), y = redBalls[i].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 11], {time = 1000, x = redBalls[i + 11].x + saved2 + mRand(-3, 3), y = redBalls[i + 11].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1) * 4
local saved2 = sqrt(40^2 - saved1^2)
transition.to(redBalls[i + 21], {time = 1000, x = redBalls[i + 21].x - saved2 + mRand(-3, 3), y = redBalls[i + 21].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 31], {time = 1000, x = redBalls[i + 31].x + saved2 + mRand(-3, 3), y = redBalls[i + 31].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1) * 3
local saved2 = sqrt(30^2 - saved1^2)
transition.to(redBalls[i + 41], {time = 1000, x = redBalls[i + 41].x - saved2 + mRand(-3, 3), y = redBalls[i + 41].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 51], {time = 1000, x = redBalls[i + 51].x + saved2 + mRand(-3, 3), y = redBalls[i + 51].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1) * 2
local saved2 = sqrt(20^2 - saved1^2)
transition.to(redBalls[i + 61], {time = 1000, x = redBalls[i + 61].x - saved2 + mRand(-3, 3), y = redBalls[i + 61].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 71], {time = 1000, x = redBalls[i + 71].x + saved2 + mRand(-3, 3), y = redBalls[i + 71].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1)
local saved2 = sqrt(10^2 - saved1^2)
transition.to(redBalls[i + 81], {time = 1000, x = redBalls[i + 81].x - saved2 + mRand(-3, 3), y = redBalls[i + 81].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 91], {time = 1000, x = redBalls[i + 91].x + saved2 + mRand(-3, 3), y = redBalls[i + 91].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
end
for i = 1, 102 do
transition.to(redBalls[i], {delay = mRand(300, 600), time = mRand(300, 500), alpha = 0});
end
end
timer.performWithDelay(4000, square, 0) [import]uid: 126017 topic_id: 31073 reply_id: 124385[/import]
When using transition.to, you will need a little bit of memory for every transition that is active. This stores current state, and the Coroutine/Closure that animates each frame. By using enterFrame you are reducing the general overhead required to store each transition state (e.g. instead of 204 time keys, you have 2, same with transition types).
It would require a pretty heavy refactor, but I find it’s a clean pattern to setup your particles with a params table on them that contains things like Velocity, Duration, Acceleration, etc…(essentially the same parameters you pass into transition.to), and then just have a simple enterFrame that moves the objects based on their parameters (Move the x,y of the object by Velocity * elapsed time, reduce duration by elapsed, and destroy object when it hits 0, etc…). By doing all your transitions manually, you end up with no transition objects being created, and have much better control on reusing shared variables, which both help reduce your memory usage.
Looking at your code, you could use 2 different enterFrame objects, or use timer.performWithDelay and an enterFrame call on the second loop through all the redBalls.
Edit: to clarify on my end, the easiest solution would be to simply not use transition.to and to manually animate your objects, since it allows you to avoid information duplication and excess memory that really wasn’t necessary.
[import]uid: 134101 topic_id: 31073 reply_id: 124386[/import]
Hey Ntero,
I was afraid that was the best solution. Thanks tho for all the help but could you please show me a example of how it would be done? If not its no biggy i will figure it out.
Thanks,
Chris Brasino [import]uid: 126017 topic_id: 31073 reply_id: 124395[/import]
particle candy addon.
Do you use imagesheets?
What does transition.to have to do with texture memory? 10 images is 10 images.
If you use a lot of images try using imagesheets. Those handle memory better. [import]uid: 100901 topic_id: 31073 reply_id: 124309[/import]
Hey Jannie,
Sorry for the confusion I didn’t mean text memory I just meant memory usage. I don’t think using image sheets would help with this. The firework effect I am creating calls about 100 small 6 pixel by 6 pixel images that spread out in a random effect looking very similar to a firework. However the transition.to that I am using to create this random scatter effect is taking way to much memory usage. I will check out particle candy, but do you have any other suggestions?
Thanks,
Chris Brasino [import]uid: 126017 topic_id: 31073 reply_id: 124381[/import]
Use enterFrame, and have 1 update transition all objects.
local updateFireWorks = nil
updateFireWorks = function()
--Do Stuff here
if done then
Runtime:removeEventListener('enterFrame', updateFireWorks)
end
end
Runtime:addEventListener('enterFrame', updateFireWorks) Just make sure updateFireWorks has a reference to all your particles. [import]uid: 134101 topic_id: 31073 reply_id: 124383[/import]
Hi Ntero,
I’m not sure that would help. The issue is that I am using so many transitions in order to create this effect. I could be wrong but here is my code showing what I am doing. Hopefully this will help reveal the problem I am talking about.
Thanks,
Chris Brasino
[lua] local sqrt = math.sqrt
local mRand = math.random;
local abs = math.abs;
local redBalls = {}
for i = 1, 102 do
redBalls[i] = display.newImageRect(“images/fireworks/redBall.png”, 6, 6);
redBalls[i].x = 160; redBalls[i].y = 160;
redBalls[i].alpha = 0;
end
local square = function(v)
for i = 1, 102 do
redBalls[i].x = 160; redBalls[i].y = 160;
redBalls[i].alpha = 1;
end
for i = 1, 11 do
local saved1 = (i - 1) * 5
local saved2 = sqrt(50^2 - saved1^2)
transition.to(redBalls[i], {time = 1000, x = redBalls[i].x - saved2 + mRand(-3, 3), y = redBalls[i].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 11], {time = 1000, x = redBalls[i + 11].x + saved2 + mRand(-3, 3), y = redBalls[i + 11].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1) * 4
local saved2 = sqrt(40^2 - saved1^2)
transition.to(redBalls[i + 21], {time = 1000, x = redBalls[i + 21].x - saved2 + mRand(-3, 3), y = redBalls[i + 21].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 31], {time = 1000, x = redBalls[i + 31].x + saved2 + mRand(-3, 3), y = redBalls[i + 31].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1) * 3
local saved2 = sqrt(30^2 - saved1^2)
transition.to(redBalls[i + 41], {time = 1000, x = redBalls[i + 41].x - saved2 + mRand(-3, 3), y = redBalls[i + 41].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 51], {time = 1000, x = redBalls[i + 51].x + saved2 + mRand(-3, 3), y = redBalls[i + 51].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1) * 2
local saved2 = sqrt(20^2 - saved1^2)
transition.to(redBalls[i + 61], {time = 1000, x = redBalls[i + 61].x - saved2 + mRand(-3, 3), y = redBalls[i + 61].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 71], {time = 1000, x = redBalls[i + 71].x + saved2 + mRand(-3, 3), y = redBalls[i + 71].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
local saved1 = (i - 1)
local saved2 = sqrt(10^2 - saved1^2)
transition.to(redBalls[i + 81], {time = 1000, x = redBalls[i + 81].x - saved2 + mRand(-3, 3), y = redBalls[i + 81].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
transition.to(redBalls[i + 91], {time = 1000, x = redBalls[i + 91].x + saved2 + mRand(-3, 3), y = redBalls[i + 91].y - saved1 + mRand(-3, 3), transition = easing.outExpo});
end
for i = 1, 102 do
transition.to(redBalls[i], {delay = mRand(300, 600), time = mRand(300, 500), alpha = 0});
end
end
timer.performWithDelay(4000, square, 0) [import]uid: 126017 topic_id: 31073 reply_id: 124385[/import]
When using transition.to, you will need a little bit of memory for every transition that is active. This stores current state, and the Coroutine/Closure that animates each frame. By using enterFrame you are reducing the general overhead required to store each transition state (e.g. instead of 204 time keys, you have 2, same with transition types).
It would require a pretty heavy refactor, but I find it’s a clean pattern to setup your particles with a params table on them that contains things like Velocity, Duration, Acceleration, etc…(essentially the same parameters you pass into transition.to), and then just have a simple enterFrame that moves the objects based on their parameters (Move the x,y of the object by Velocity * elapsed time, reduce duration by elapsed, and destroy object when it hits 0, etc…). By doing all your transitions manually, you end up with no transition objects being created, and have much better control on reusing shared variables, which both help reduce your memory usage.
Looking at your code, you could use 2 different enterFrame objects, or use timer.performWithDelay and an enterFrame call on the second loop through all the redBalls.
Edit: to clarify on my end, the easiest solution would be to simply not use transition.to and to manually animate your objects, since it allows you to avoid information duplication and excess memory that really wasn’t necessary.
[import]uid: 134101 topic_id: 31073 reply_id: 124386[/import]
Hey Ntero,
I was afraid that was the best solution. Thanks tho for all the help but could you please show me a example of how it would be done? If not its no biggy i will figure it out.
Thanks,
Chris Brasino [import]uid: 126017 topic_id: 31073 reply_id: 124395[/import]