Pooling of multiple derived classes or interfaces?
Monkey Forums/Monkey Programming/Pooling of multiple derived classes or interfaces?
| ||
| Hiya, So I need to write yet another particle generator for a project. My last one didn't do any sort of resource re-use or pooling, and was heavily interface-based. As a result, it choked up a lot, and I was generally unhappy with that. This time around, I'm running up against a deadline and just need a few separate classes of particle. However, I still want to manage them using a similar interface, at least I think I do. My basic question would be, what would be a good way of going about handling a few separate types of particle that are different enough where having a "master" base class would be unwieldy, but interfaces preclude an easy way to re-allocate resources in a ringbuffer or pool? Can I use brl.pool for this? Should I just give up and make another obscenely large master particle class? Perhaps there's another way I can pool the resources of the disparate particles and re-use "dead" ones quickly and easily... |
| ||
| If you really need to have multiple particle implementations then you'll need a pool for each type. Presumably if you're creating different types anyway then allocating from multiple pools isn't a problem. If you want to centralise the processing and recycling then store the parent pool reference on the particle and have the common interface include a Discard method or similar. When the particle lifetime is over the particle manager calls the discard method and the particle returns itself to the pool it came from. I suspect that you can rejig your particle system to avoid the need to have multiple types but if you're up against a deadline then the above should work for you. |
| ||
| Thanks, I decided to write a new system since the old one had a bit of a fundamental problem with this allocation stuff. I think writing an allocator for my old system would just be trying to put a band-aid on a fundamentally flawed design. I talked with some people I know last night and it seems to me that a better way to go about this would be to create a god particle, even though that runs the risk of bloat with the design. At least with a master base particle, allocation and re-use of resources is easy. I wrote a new generator specifically for this game and tried to keep the hierarchy general but basic enough so that derived classes could use the same fields and still do what I needed them to do. (Extra information for anyone who's interested: The fields in my new implementation are variations of ParticleValues from argyne -- all tweenable values in the master particle of are of either scalar or 2d types I call pVal and pVal2 that use a custom easing curve specified by an interface. This only allows for simple, 1-directional movement for right now, and requires a separate allocator for any particle type requiring more tweenable fields than the base one -- such as those for advanced movement -- but when I have more time I'll re-do pVal2 so that a path can be specified instead or just a startpoint and endpoint, and there will be little-to-no need to expand the master particle beyond its existing fields. If this proves to be successful for us, then I might release it as argyne's successor eventually.....) |
   |