How are you avoiding memory Increas
BlitzMax Forums/BlitzMax Programming/How are you avoiding memory Increas
| ||
| Im testing a process where a space ship shoots missiles and when the missiles explode the memory should be free. my Type is constructed more or less like that
Type SpaceShip
Field MeshHandle
Field Sons:TList
Field Physical:PhysicalData_Type
Field XPos#
Field YPos#
etc...
End Type
So what I have is a Class which has Fields That are Classes too. So I FreeEntity MeshHandle and Then I Do SpaceShip=Null Do I also Need to do Null for the Internal Parts like Physical field etc.. Anyway.. I get memory Increase So something is Wrong.. What Is the Proper way to clear a Game Element in order to keep Memory Stable and not gradually increased? |
| ||
| BlitzMax does not have a command "FreeEntity" - I assume you are posting in the wrong section of this board. Memory increases because Garbage Collection does not take place each time an object gets "collectable". If an object is not linked from somewhere anymore, it gets collectable. myobject -> list -> otherobject Delete myobject and list gets collectable - which makes otherobject collectable. myobject -> thislist -> otherobject secondobject -> thislist -> otherobject Delete myobject and thislist/otherobject/secondobject keep existing Delete thislist and otherobject gets deleted, secondobject gets kept thislist -> otherobject -> myobject thislist -> myobject -> otherobject if you now delete thislist, you created a mem leak as nobody knows about otherobject/myobject, but both of them know about each other - so they do not get GCed. To avoid this, manually "clear/empty" this list before setting it null. Or just avoid circular referenced (otherobject->myobject and myobject->otherobject at the same time). bye Ron |
| ||
| Derron i use xors. Thats why ive mentioned freeentity. Its the principle that matters anyway. Now im gonna try understanding your explanation. Tnx |
| ||
| I would suggest to encapsulate access to non managed memory members in your program, to keep safe from future crashes. Make any object that requires to be manually free "private" and automatically release it on the Delete method, just in case you forget to free it in other areas of the program. This way, you will avoid big memory leaks (only leaks while the GC is not yet collecting objects). Additionally, I would suggest to encapsulate collection of entiities so a managed "Collect" or "Destroy" or whatever method can be used to actually call the xors freeentity command AND at the same time, set a flag in your managed class, so you can debug the areas where something is free twice, or accessed after being free. |
| ||
| Another idea is using suitably sized arrays and encapsulating them. Stacks can also work very nicely for this purpose but that's basically a way of handling data within an array. If you handle particles this way you can get good speed improvements because it doesn't have to garbage collect at all. I can write an example for you if you want. |
   |