It’s that the physics bodies are still hanging around when the display objects were already removed (or when a scene is already purged). Graphics/images weren’t there anymore but when the hybrid debug mode is turned on, physics bodies show.
What is the efficient way of removing physics bodies without messing up the entire application? See, I’ve tried using physics.removeBody() but I don’t think it’s what I’m looking for. I’m using isBodyActive now. But if there’s a much more efficient way of doing so (removing physics bodies upon removing display objects), can you guys tell me?
If you’re removing the objects properly, the physics body will be deleted along with them. If they’re hanging around, then there’s probably some kind of scoping issue or error in the code that’s causing it.
If you want to keep the physics bodies around for another scene (or to have them present again when you return to that scene), making them inactive (isBodyActive = false) is perfectly valid… in fact, in some cases it’s more efficient to do that instead of deleting and recreating them.
I’m confused about what objects must be removed separately if you use removeScene and purgeScene. Doesn’t anything that is inserted into the screenGroup (set to self.view) get removed? I have some physics objects that don’t seem to be removed as well, even though they are in screenGroup. Do I need to do some manual removal as well?
So I think I saw the answer to my question in this older thread: http://developer.coronalabs.com/forum/2012/07/08/storyboard-what-remove#comments. I’ve declared a display group (that holds my physics objects) outside of the function createScene. Although this is inserted into screenGroup (which is declared in the createScene function), does that make it global so that I need to remove it separately?
I also noticed that someone said “RemoveScene will do the same thing as purgeScene and then proceed to unload the module from memory.” Does that mean that I can just call removeScene by itself (and not call purgeScene)?
Objects inserted into the scene’s group should be removed automatically along with the scene, but that doesn’t necessarily mean they are fully cleaned up (from memory). If you have references to them that were declared outside of the scene, they must be handled separately. The basic rule of thumb is: when you remove a display group (which a scene is, in itself), the display objects inside will be removed, but if you have references to them elsewhere, their Lua memory will not be freed. Now, if those objects and their declarations are all “localized” to the scene module (whether inside the createScene function or not), they should be cleaned up when you remove the module from memory.
Removing a scene is what fully clears it from memory. You should be able to just remove the scene without purging it first (which is reserved for if you want to just clear the scene temporarily but bring it back later, faster, without re-creating it).
I have a question regarding the references to objects:
I was creating a table for storing objects like this:
objtable={}
– now whenever an object in the code is created like for example…
myhero=newSprite (…)
– I add it like this to the table:
objtable[#objtable+1]=myhero
Later in the code, when I want to delete all objects I call a function who goes through the objtable like for example:
for x=#objtable,1,-1 do
if objtable[x].parent then
objtable[x]:removeSelf()
objtable[x] = nil
end
end
Before deleting the objects like this I also had some external modules access the objects and doing transformations and stuff like for example:
mymodule.myhero.xScale=0.5
or
inside an extern module:
newlist[1]=mymodule.myhero
My questions are now …
what exactly is a reference to myhero? Is it already a reference, when I do transformations from an extern module, or do I have to “add” myhero to another variable or list? Does this mean I have to set this “reference” to nil also, when setting the objtable to nil?
is the objtable the right way to get hold of display.objects for removal?
is the “objtable[x].parent” part in the code above correct? I used this because of an error I got with only using “objtable[x]” instead. (The error was, the objects already was nil… maybe because a displayGroup was deleted or something)
Is there an example somewhere explaining how to access display.objects from external modules and deleting them correctly? I couldn’t find anything regarding this topic?
When deleting everything correctly, the texture memory usage should be (near) zero again, right? How do I have to get hold of the images and references to catch everything, so I have total control over the texture memory?
I always thought removing the objects like above and setting nil is the correct way to do things, but my texture memory only is removed from 100% to about 60% when I do it like shown above. So any help is welcome!!!
Any time you assign a variable to an object, either as a sole variable or part of a table, that’s creating a reference to it. So, when you create an object, that’s one reference, then when you add that item to the “objtable” table, that’s a second reference. You need to make sure you manage all of these, and remove all of them when you’re completely done with the object.
You can manage display objects in other ways, not necessarily by placing them into a holding table (that’s just my term for it, but other developers may call it something else). It totally depends on your app setup and needs re: how you need to access these object references.
Consider using “display.remove()” instead of “:removeSelf()”. http://docs.coronalabs.com/api/library/display/remove.html. This is the equivalent of “if the object is not nil then remove it”. So, using that, you shouldn’t get any “it was already nil!” warnings/errors.
How you pass variables and references around is up to you. I can’t think of any specific examples that show this in action, but maybe somebody else has a good example/link.
Texture memory is separate from program memory. If your texture memory isn’t being reduced to near 0 when you remove all objects, then there’s probably something clogging them in memory. Texture memory should actually reduce immediately when you remove an object from the display, not necessarily when you nil it out from program memory. So, calling “display.remove” on an image should reflect a reduction in texture memory on/near the next app cycle, assuming that you don’t have another “copy” of that texture somewhere. If that’s not happening, then something is not being cleared properly.
If you’re removing the objects properly, the physics body will be deleted along with them. If they’re hanging around, then there’s probably some kind of scoping issue or error in the code that’s causing it.
If you want to keep the physics bodies around for another scene (or to have them present again when you return to that scene), making them inactive (isBodyActive = false) is perfectly valid… in fact, in some cases it’s more efficient to do that instead of deleting and recreating them.
I’m confused about what objects must be removed separately if you use removeScene and purgeScene. Doesn’t anything that is inserted into the screenGroup (set to self.view) get removed? I have some physics objects that don’t seem to be removed as well, even though they are in screenGroup. Do I need to do some manual removal as well?
So I think I saw the answer to my question in this older thread: http://developer.coronalabs.com/forum/2012/07/08/storyboard-what-remove#comments. I’ve declared a display group (that holds my physics objects) outside of the function createScene. Although this is inserted into screenGroup (which is declared in the createScene function), does that make it global so that I need to remove it separately?
I also noticed that someone said “RemoveScene will do the same thing as purgeScene and then proceed to unload the module from memory.” Does that mean that I can just call removeScene by itself (and not call purgeScene)?
Objects inserted into the scene’s group should be removed automatically along with the scene, but that doesn’t necessarily mean they are fully cleaned up (from memory). If you have references to them that were declared outside of the scene, they must be handled separately. The basic rule of thumb is: when you remove a display group (which a scene is, in itself), the display objects inside will be removed, but if you have references to them elsewhere, their Lua memory will not be freed. Now, if those objects and their declarations are all “localized” to the scene module (whether inside the createScene function or not), they should be cleaned up when you remove the module from memory.
Removing a scene is what fully clears it from memory. You should be able to just remove the scene without purging it first (which is reserved for if you want to just clear the scene temporarily but bring it back later, faster, without re-creating it).
I have a question regarding the references to objects:
I was creating a table for storing objects like this:
objtable={}
– now whenever an object in the code is created like for example…
myhero=newSprite (…)
– I add it like this to the table:
objtable[#objtable+1]=myhero
Later in the code, when I want to delete all objects I call a function who goes through the objtable like for example:
for x=#objtable,1,-1 do
if objtable[x].parent then
objtable[x]:removeSelf()
objtable[x] = nil
end
end
Before deleting the objects like this I also had some external modules access the objects and doing transformations and stuff like for example:
mymodule.myhero.xScale=0.5
or
inside an extern module:
newlist[1]=mymodule.myhero
My questions are now …
what exactly is a reference to myhero? Is it already a reference, when I do transformations from an extern module, or do I have to “add” myhero to another variable or list? Does this mean I have to set this “reference” to nil also, when setting the objtable to nil?
is the objtable the right way to get hold of display.objects for removal?
is the “objtable[x].parent” part in the code above correct? I used this because of an error I got with only using “objtable[x]” instead. (The error was, the objects already was nil… maybe because a displayGroup was deleted or something)
Is there an example somewhere explaining how to access display.objects from external modules and deleting them correctly? I couldn’t find anything regarding this topic?
When deleting everything correctly, the texture memory usage should be (near) zero again, right? How do I have to get hold of the images and references to catch everything, so I have total control over the texture memory?
I always thought removing the objects like above and setting nil is the correct way to do things, but my texture memory only is removed from 100% to about 60% when I do it like shown above. So any help is welcome!!!
Any time you assign a variable to an object, either as a sole variable or part of a table, that’s creating a reference to it. So, when you create an object, that’s one reference, then when you add that item to the “objtable” table, that’s a second reference. You need to make sure you manage all of these, and remove all of them when you’re completely done with the object.
You can manage display objects in other ways, not necessarily by placing them into a holding table (that’s just my term for it, but other developers may call it something else). It totally depends on your app setup and needs re: how you need to access these object references.
Consider using “display.remove()” instead of “:removeSelf()”. http://docs.coronalabs.com/api/library/display/remove.html. This is the equivalent of “if the object is not nil then remove it”. So, using that, you shouldn’t get any “it was already nil!” warnings/errors.
How you pass variables and references around is up to you. I can’t think of any specific examples that show this in action, but maybe somebody else has a good example/link.
Texture memory is separate from program memory. If your texture memory isn’t being reduced to near 0 when you remove all objects, then there’s probably something clogging them in memory. Texture memory should actually reduce immediately when you remove an object from the display, not necessarily when you nil it out from program memory. So, calling “display.remove” on an image should reflect a reduction in texture memory on/near the next app cycle, assuming that you don’t have another “copy” of that texture somewhere. If that’s not happening, then something is not being cleared properly.
