How do i delete unused objects?
BlitzMax Forums/BlitzMax Beginners Area/How do i delete unused objects?
| ||
| As i create objects such as partices and bullets in my game i add everything to a list which i then interate through to update and draw the objects. When an object is exiting the screen or "dies" in some other way i tell the object to remove itself from the list. What just struck me is that does this mean i never really delete the object itself and only the link to it through the list? I havenīt found any answers to this here that i feel happy with and i wonder how i make sure that unused objects are deleted? I read that the "flushmem" command clears objects with no pointers to them. Is that all i need to add to get rid of the objects iīm talking about? There should be nothing in my code that tries to access any objects outside the lists. /Peter |
| ||
| locals that have gone out of scope and objects you have no way of accessing any more and as long as there are no two variables referencing each other, will be automatically collected and restored by the garbage collector. A "garbage collector" is a small program that runs integrated with any Blitzmax applications/games that you create and is responsible for cleaning the program while it's being executed. it has its advantages and disadvantages and depending on how you use it it can be a blessing or a curse. constantly creating and removing many objects can decrease it's function ability and cause the program to come to a crawl randomly. A way to prevent this like with any other language is by recycling objects as this prevents the garbage collector from working too hard to restore memory and for the memory to be available for new objects. Last edited 2010 |
| ||
| Each object remembers if something is pointing to it. Once nothing is pointing to it, it is ready for Garbage collection. An object pointed to only within a function needs to be put on some sorta list (map etc), so that when the function finishes, it still exists. DONT worry about GC at all unless you are allocating Banks/memory blocks or the like, in which case read up on them. If you have speed/timing issues turn off the GC for calc intensive low variable creation routines, then back on after these. Generally just dont worry about it, if you can get to it it exists, if you cannot then it probably don't |
| ||
| Make a global count variable, and in Method New increase it by 1 and in Method Delete decrease it by 1. Print it to the screen and you can see if your objects are being deleted or not. Note: don't use Method Delete for anything else, it's a special internal method and shouldn't be fiddled with. But for a debug check like this, it's ok to experiment. |
| ||
| It is ok to use the delete method. It gets called when an object gets removed from memory. But you cannot guarantee that it will be called for all objects when your program ends. |
| ||
| Thanks for the answers. The recycle object approach mentioned here sounds very interesting. Would that be as simple as moving the unused objects to a separate list, which i then look into for an object of the right type before i create a new one? |
| ||
| Yes, using the delete method is fine. The only caveat is that you should not use it for anything critical, since there is no absolute guarantee that it will be called. Yes, it would be as simple as moving unused objects to a new list (or array) which you later access when you need to create a new one. Pooling will be particularly beneficial if you're using the threaded GC which is quite a bit slower than the standard GC. Either way, it's a nice concept to understand as it can be vital with speed-sensitive stuff (eg: particles.) |
| ||
| So with those restrictions in mind, can anybody tell me any useful, non-debug purposes of the delete method? As for pooling, it's best to maintain a seperate list for each type and removelast one when needed (or create new if empty). This isn't just to save time scanning a list, say you have a non-abstract base type, how do you know what you're getting from the list is a real base and not a derived? There are solutions but simpler just to have a unique list for each declared type. You can't put the type in the list in the delete method as a way to hijack the collector, that can result in strange things. You need to manually "delete" the object with your own normal function. My game creates and deletes objects like there's no tomorrow and it runs fine, so don't get all worried about pooling. |
| ||
| So with those restrictions in mind, can anybody tell me any useful, non-debug purposes of the delete method? Well I use the delete method to indicate a change in the reference count of managed objects. For example, in the delete method of a Material (set of visual properties) I reduce the reference count of all textures that material used. On the offchance that the delete method is never called.. well it doesn't matter because if the program should end before the delete method is called, all textures get unloaded when the program ends anyway, |
| ||
| Good example. |
| ||
| the delete function is useful for deleting textures in openGL when there are no images using the texture.... apart from that i dont use it |
   |