Reputation: 151
I'm having trouble grasping some concepts relating to objects in memory and I would be very grateful if someone could put me on the right track. I realize how important managing memory is and I'm concerned that I'm adopting bad programming habits.
In my game loop I use lambda expressions in the following format to remove objects from my game:
ObjectsMan.lstExplosionParticles.RemoveAll(particle => particle.TTL <= 0);
These objects are usually instantiated inside list add methods, for example:
ObjectsMan.EnemyShots.Add(new EnemShot(current.SpritePosition + position.Key,
Logic_ReturnValue.Angle_TarPlayer(current), position.Value));
As far as I understand it, the list is storing the object's memory location. So when I remove it from the list, the object still exists in memory. Is that correct?
If that is indeed the case, could many of these objects sitting in memory cause game lag (for example, thousands of individual projectile objects) even if I'm not drawing them? Do I need to manually assign each object to null?
Additionally, if I don't impose a frame rate cap on my game's draw method, am I correct in thinking that I'm losing a massive amount of performance due to frames being drawn that the human eye can't see?
Another question is that when if I stop my game using the debugger and a sound is playing, my sound driver locks up. I thought that calling my sound effect's Stop method would prevent this. Does the debugger bypass XNA's unload content method when it stops? What is happening here?
Lastly, if I include extra using statements that I don't technically need, is that impacting my memory? For example most of my classes include a few using statements that they don't actually need. Is there a performance related reason to clean this up, or is it just good programming practice?
I would greatly appreciate it if someone could give me some help or point me in the right direction with this.
Thanks.
Upvotes: 1
Views: 285
Reputation: 12849
As far as I understand it, the list is storing the object's memory location. So when I remove it from the list, the object still exists in memory. Is that correct?
Yes. You are just removing references to the objects.
If that is indeed the case, could many of these objects sitting in memory cause game lag (for example, thousands of individual projectile objects) even if I'm not drawing them?
Directly? No. But they will cause lags when GC finally kicks in. Simply because GC has many more objects to take care of. I had exactly same problem on Xbox360, that didn't have generational GC.
Do I need to manually assign each object to null?
That is just removing the reference. Same as removing it from list.
Lastly, if I include extra using statements that I don't technically need, is that impacting my memory? For example most of my classes include a few using statements that they don't actually need. Is there a performance related reason to clean this up, or is it just good programming practice?
There should be no problem here.
The GC doesn't kick in until the end of the program, is this correct?
Wrong. The GC can run at any point in time. Usually if application decides it is running low on memory and OS can't provide any, it will run the GC.
Just because I've removed the objects from a list, that shouldn't give the GC grounds to remove my object from memory?
If this list held the only reference, then GC is free to remove the object. But is not related if GC is actually ran at that moment.
Also, usually, when programming a game, you should limit number of objects you create. Simply because running a GC can create lots of unpredictable lag. Either use structures or reuse existing instances. In case of particle system, best way would be to have structure for each particle and field saying if the particle is active. When removing particle, you just set this field to false. When adding new particle, you will find first that is not active and set appropriate fields and activate it.
Upvotes: 3