It looks like you're new here. If you want to get involved, click one of these buttons!
local textfield = nil -- texfield 1 textfield = TextField.new(nil, "my first text") self:addChild(textfield) -- texfield 2 textfield = TextField.new(nil, "my second text") self:addChild(textfield) |
Comments
function add_text_to_sprite(sprite)
local textfield1 = TextField.new(...)
sprite:addChild(textfield1)
local textfield2 = TextField.new(...)
sprite:addChild(textfield2)
end
add_text_to_sprite(my_sprite)
Since the two text fields are local variables, local to the function, the variables are gone after the function returns, but the text fields remain as children of my_sprite. There's no harm in doing the same with a single variable:
function add_text_to_sprite(sprite)
local textfield = TextField.new(...)
sprite:addChild(textfield)
textfield = TextField.new(...)
sprite:addChild(textfield)
end
add_text_to_sprite(my_sprite)
That has exactly the same effect. The more important factor is to use a variable that's local to the scope where you need it.
In your example, when you create the second TextField, you're reusing the variable you created for the first one. The only way you'd be able to access the first one again would be to get the child of the Sprite you added it to. Suppose later you wanted to change the text in the first one. If you wrote:
textfield:setText("new text")
that would change the text of the second one created. To change the text in the first one you'd have to do something like:
textfield = self:getChildAt(1)
textfield:setText("new text")
Which only works if you're keeping track of the number of children in the sprite where you added it, so you know which child is the TextField you want to change.
So I'd say feel free to reuse variable names (there can even be memory advantages to doing so) but only when you know you won't need to access whatever it was the variable originally referred to again.
Paul
Likes: MoKaLux
Thank you very much for your detailed answer, very much appreciated.
local textfield
Likes: MoKaLux, oleg
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
“The more you do coding stuff, the better you get at it.” - Aristotle (322 BC)
In all tests I'm creating a grid of textfileds.
test1: create textfiled, add it to scene, add it to local table (t).
test2: create textfiled, add it to scene
test3: create textfiled, add it to scene, add it to global table (globalTable).
test4: create textfiled, add it to scene, add it to scene table (scene.t).
Tweak CLEAR_GLOBAL_TABLE and DELETE_SCENE "variables" to see how they affect memory usage
Likes: MoKaLux
I am going to give it a try and see what I've got. Thank you for your help.
But I guess, if you are using SceneManager, then it should not be a problem.
but after manual 'collectgarbage()' call they get collected
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
“The more you do coding stuff, the better you get at it.” - Aristotle (322 BC)
If you delete the link to the parent sprite, you need to collect garbage twice to collect his children
Likes: Apollo14
https://play.google.com/store/apps/developer?id=razorback456
мій блог по гідерос https://simartinfo.blogspot.com
Слава Україні!
Likes: oleg
https://deluxepixel.com
In the 3D asteroid sample, I'm never calling collectgarbage(). New asteroids are created every few frames, and each gets added to a sprite in the scene. No variable is kept that references it. When the asteroid moves out of sight behind the camera, or gets destroyed, I remove it from its parent. When the ship is destroyed it creates 500 meshes for fragments of the ship, and each of those gets removed from the scene after a certain number of frames. Each asteroid destroyed creates 50 fragments that behave the same way. In theory, the memory for all those asteroids and fragments could get freed up anytime after they've been removed from the scene.
I was curious to see if automatic garbage collection would keep up with all the asteroids and fragments that have been removed from the scene, or if the memory usage would continually climb. It seems the automatic collection handles this just fine. I can leave the game running for an extended period of time and the memory usage stays within the usual range.
Still, calling collectgarbage() periodically is probably a wise practice in general, especially using the method @SinisterSoft suggested.
Likes: Apollo14, SinisterSoft, antix
Fragmenter - animated loop machine and IKONOMIKON - the memory game