Hey Norbo, I've got a problem I'm struggling with right now, which I'll bet is a pretty basic one, but owing to my lack of mastery of BEPU and all its many wonders, I'm dreading how long it might take me tomorrow to figure out -- so I thought I'd make a quick post and see if you have time to point me in the right direction.
Basically, I'm working on making all projectiles in my game get drawn from the same central resource pool. I've used your projectile and projectile manager classes in the blocks explode your castle example game as a starting point. The challenge is, my projectiles are going to be inherited from.
Now, my difficulty is this: I want arrows to be shaped like arrows (a long, thin box will work), and I want bombs to be shaped like spheres. So I made the projectile class contain a general "Entity" type, so I can give it any shape. The problem is, the new shape being created is exactly the memory allocation I'm trying to avoid by making all projectiles come from a resource pool. If I have to recreate the shape every time I draw a projectile from the resource pool, it will defeat the purpose of the pool. But is there a way to change the shape when drawing it out of the pool, without incurring some memory allocations? Or, would it be better to just create a pool for each conceivable shape of projectile (I suppose there are only 2 or 3) and simply resize the shapes when the projectile is being used?
Anyway, thanks for listening, Norbo. I'm getting quite close to being able to show off a demo of this game I've been working on, and it definitely wouldn't have been possible without you.*
Alex
*Oh, and expect some christmas cheer from me in the near future :p
Best way to do resource pool with changing entity shapes?
Re: Best way to do resource pool with changing entity shapes
The simplest option would probably be just maintaining multiple pools of entities, each pool created from one shape. Since a shape can be shared among any amount of entities, a bit of memory is saved and no garbage creation is necessary.But is there a way to change the shape when drawing it out of the pool, without incurring some memory allocations? Or, would it be better to just create a pool for each conceivable shape of projectile (I suppose there are only 2 or 3) and simply resize the shapes when the projectile is being used?
Another option is to use a resource pool containing MorphableEntity objects. Use additional resource pools which each contain EntityCollidables of the appropriate shared shape. You can create instances of EntityCollidables by using a shape's GetCollidableInstance() method. When pulling a MorphableEntity out of the entity pool, grab an EntityCollidable from the desired collidable pool, set the entity's CollisionInformation to the new EntityCollidable, and give the old EntityCollidable back to the pool (you'll need to grab a reference to it before setting the CollisionInformation property).
Morphable entities must have a valid EntityCollidable at all times, though. When they are inactive in the pool, they will be holding an EntityCollidable which would otherwise be in one of the other pools, available for use. When they are pulled from the pool, the proper collidable is set and the old collidable is returned to the pool.
Using MorphableEntities might save some space. Entities are larger in memory than most collidables. However, if you don't really care about space and do care about implementation difficulty and avoiding bug-prone code, it may be best just to do go with the simpler multiple-entity-pool approach.
Oh, and expect some christmas cheer from me in the near future :p
Re: Best way to do resource pool with changing entity shapes
Hey Norbo, thanks for your help! I'm going with the multiple-resource pool approach.
I hadn't considered instantiating one shape and then using it to construct all the entities in a pool. I'm actually not sure that will work for me the way I want, but I could be wrong. When I get objects out of the pool, one of the things I'm going to be doing is resizing them -- that way sphere shaped projectiles coming out of the pool could be used for many different types of projectiles.
My question is, if I create the entities in the pool by passing in one SphereShape object, won't getting one entity out of the pool and changing its Radius property change the radius for every other object in the pool?
Thanks for reading,
Alex
p.s. To avoid having to hook up events after getting objects out of the pool, I'm thinking about creating a ContactEventManager<EntityCollidable> independently of the object which goes in the pool, and then passing it by reference when getting objects out of the pool. That way I can have longer persisting objects which hook methods up to the EventManager, and still have my pool objects raise those events. My question is: this will work, right? And not do anything weird, like... generating garbage, for example? Hmm, now that I think about it, it might generate some garbage... is the ContactEventManager instantiated when the entity is, or is it only instantiated when the property is first accessed?
I hadn't considered instantiating one shape and then using it to construct all the entities in a pool. I'm actually not sure that will work for me the way I want, but I could be wrong. When I get objects out of the pool, one of the things I'm going to be doing is resizing them -- that way sphere shaped projectiles coming out of the pool could be used for many different types of projectiles.
My question is, if I create the entities in the pool by passing in one SphereShape object, won't getting one entity out of the pool and changing its Radius property change the radius for every other object in the pool?
Thanks for reading,
Alex
p.s. To avoid having to hook up events after getting objects out of the pool, I'm thinking about creating a ContactEventManager<EntityCollidable> independently of the object which goes in the pool, and then passing it by reference when getting objects out of the pool. That way I can have longer persisting objects which hook methods up to the EventManager, and still have my pool objects raise those events. My question is: this will work, right? And not do anything weird, like... generating garbage, for example? Hmm, now that I think about it, it might generate some garbage... is the ContactEventManager instantiated when the entity is, or is it only instantiated when the property is first accessed?
Re: Best way to do resource pool with changing entity shapes
Yup. If every entity has the same shape instance, changing the dimensions will be reflected in every entity.My question is, if I create the entities in the pool by passing in one SphereShape object, won't getting one entity out of the pool and changing its Radius property change the radius for every other object in the pool?
That area is a bit convoluted and it's been a while since I've fiddled with it, but it should be possible given some care. For example, the event manager tracks its owner so you could not give an event manager to an entity if it was not constructed for that entity.I'm thinking about creating a ContactEventManager<EntityCollidable> independently of the object which goes in the pool, and then passing it by reference when getting objects out of the pool. That way I can have longer persisting objects which hook methods up to the EventManager, and still have my pool objects raise those events. My question is: this will work, right? And not do anything weird, like... generating garbage, for example?
I think I'll look into the event manager a bit to see if I can clean it up- I'm not confident that event managers set after construction will work at all at the moment. I'll probably also shift some things around so that ownership is more clearly defined, though there will still be a one-to-one requirement between event managers and collidables.
Re: Best way to do resource pool with changing entity shapes
The development version now includes the mentioned changes:
http://bepuphysics.codeplex.com/SourceC ... evelopment
http://bepuphysics.codeplex.com/SourceC ... evelopment