cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   Vanny
   Member

   I'm getting memory errors and it's probably because of a lack of understanding pointers. I have an instance variable in my game layer that is of a projectile class I made. The projectile has a box2d body and a CCsprite.

   So every time a player shoots using an end touch a new projectile is created/assigned to the instance variable, box2d body and all. The reason I assign it to the instance variable is because I need access to that single projectile in other methods to aim and manipulate it for my game. I'm detecting collisions with the projectile, adding to a toDestroy array and removing the ccsprite and body from the scene. Every once in a while I get a memory error when I try to add a new projectile to the layer. Should I not be reusing the instance variable to create objects that remain in the scene?

   My error happens occasionally when the game tries to add a new projectile body. Not sure how there is a memory issue creating something new.

   Sorry I don't have code it would pretty much be the entire game. I'm more looking for programming concepts.
   Any best practices I should follow to create, change and dispose of projectiles?

   Posted 3 months ago #
2. 

   Vanny
   Member

   This is still baffling me, anyone have any insight? Would be much appreciated.

   Posted 3 months ago #
3. 

   slembcke
   Administrator

   Without knowing more information, I would have to guess you are running into dangling pointers.

   Posted 3 months ago #
4. 

   Dragyn
   Member

   @slembcke: "dangling pointers" always sounds more like a medical problem than a programming one...

   @Vanny: A general "best practice" for something like a projectile is to use an pool of objects that you reuse. So you would create 10 projectiles (assuming they are all the same type of projectile), store them in an array, and then you would pick the next available one, and use it. If you need to keep an iVar to it, you can always set that iVar to point to the specific element of the array that has your current "live projectile". When it is destroyed, instead of destroying the entire object, you make it invisible and flag it as dead (a BOOL in the object class would do nicely). This removes the overhead of creating them on the fly, and also removes the possibility of calling a "dangling pointer".

   For some general "best practices", I'd suggest checking the tutorials at http://raywenderlich.com. There's a good 3 part tutorial on a basic game that has pretty efficient projectile handling (but no physics engine), and a good Box2D breakout-clone tutorial series that has some good ideas on how to handle box2D collisions over a range of objects (blocks, in his case).

   Good luck!

   Posted 3 months ago #
5. 

   Birkemose
   Moderator

   Ahhh ... pools ...

   Posted 3 months ago #
6. 

   slembcke
   Administrator

   Ugh. Pools are *definitely* not a best practice. They are one of the last things you should consider doing, and only when you are trying to optimize your performance. If he's already having memory issues or dangling pointers, using pools is going to make that much worse (the bugs will still be there, but they'll end up being much more subtle and harder to find).

   Pools are good for two things. 1) Avoiding the construction/destruction cost, which for most objects is too small to care about unless you are talking on the orders of 100s of them per frame. 2) Being more CPU cache friendly, by allocating a big chunk of memory and splitting it up into a pool (this is incompatible with Objective-C objects). Chipmunk pools memory pretty extensively, but it was done because of #2 which resulted in a large performance gain (50% or so). The performance hit from #1 was more like 1-2% at most.

   Keep it simple, make it work, and *then* make it more complicated by adding optimizations to fix the performance problems, but only after you run your game in the profile to track down which places need it the most. People are surprisingly bad at guessing where CPU time is actually being used in their programs. Don't speculate.

   Posted 3 months ago #
7. 

   Karl
   Member

   Second seimbcke's post. Don't succumb to cargo cult programming. It's essential that you learn WHY something works the way it works. If you don't understand why a bug got fixed, you haven't actually fixed it.

   Posted 3 months ago #

RSS feed for this topic

Reply

You must log in to post.