Miguel: "I'm short on time, but in a nutshell my opinion is...".
That's exactly what I meant; I seem to have a skill at not being clear sometimes. As far as being arrogant, I'm more of a modest and humble person. Back to the discussion... You can easily create a particle system using dynamic or static allocation. Choosing either one I believe is a matter of preference as both will get the job done. I think the real thing to keep in mind when designing your system is to maximize its advantages and minimize its disadvantages. Here is what I can think of offhand. =============== Dynamic system =============== Advantages: Efficient memory management. This of course depends on the data structure you decide to go with. Linked lists obviously don't waste any space (except for the prev/next pointers), but an STL Vector on the other hand can pad empty array elements as it reaches its limit to help speed its insertion time. Fast insertion/deletion. Inserting into a linked list (as is deleting) is simple and fast; just a matter of calling delete/free and fixing up the prev/next pointers. Unlimited number of particles and/or particle emitters. Disadvantages: Run-time memory allocation/deallocation. Two parts to this one: speed and fragmentation. You can lessen the speed hit by not doing crazy stuff in your constructor. Some people blame new and malloc (which are pretty fast by themselves) for bottlenecks without double checking what they're doing in their constructor. Fragmentation. This may or may not matter, but in the case of a Quake-style heap, it means fragmented memory. Possibility of leaked or dangling pointers. This only applies of course while the system is in production. Once the data structure is solid, this wouldn't be an issue. ============== Static system ============== Advantages: No run-time memory allocation/deallocation hits. Memory is stored consecutively with no fragmentation. Some implementations may not guarantee that arrays are given consecutive memory, but normally there are. Disadvantages: Larger footprint with the possibility of lots of wasted memory. Not much you can do about this other then set a reasonable size for the particles array. Slower insertion/deletion. Static arrays require more housekeeping then a linked list. But how about this for keeping track of what array elements are empty? Add a member to the particle emitter class (inside this class would be the array of particles) that stores the beginning index of empty "slots". Anytime you need to create a new particle, use the empty_index to determine where to insert, and then increment it. When you delete a particle from the list, copy the particle info from the last occupied slot into the slot where the particle is being removed. Then decrement the empty_index. I haven't actually tries this, but it sounds like it would work. Obviously you would have to clamp the empty_index so you don't go outside the bounds of the array. There are some drawbacks to this such as copying over particle data for a particle that is about to die, but what can you do? Restricted number of particles and/or particle emitters. ============== I'm sure there are more adv/disadv, feel free to add any I missed. -scottv Miguel Aleman writes: > Iain, I'm not sure how you interpreted Scott's comment. If he mean what you > said he could have said something such as "Sorry I cannot be more detailed, > but I'm too busy to debate..." or "I'm short on time, but in a nutshell my > opinion is...". However, he insisted on saying something much more abrasive > than was necessary. > > On to the particle engine topic, which is infinitely more interesting... > > Sure, having the ability to create a *variable* number of particles is a > plus by using a linked list over an array. Why have 20,000 dormant > classes/structures taking up memory when you don't have to? How about > allocating new particles? Are you supposed to scan through the entire array > each time you wish to create a new particle to find that indexes 919 and > 9294-12300 are free? By using a linked list, you can simply store a pointer > to the last particle and then add on to it as necessary. > > Rendering particles in a linked list would take about the same amount of > time as rending particles in an array. Using the array, you would increment > the index, test the particle's validity, and then render it. Using the > linked list, you would render the particle, and then render the particle > connected to it until you reach the end of the list. Any speed advantage > would be negligible. > > A possible reason why indexes are used in engines such as Half-Life for > entities are because they are relatively long-life variables. You are never > going have several thousand entities appear on the screen only to later have > them disappear in 3/4s of a second. Also, the number of (non-particle) > entities in an entire scene is usually much less than the particles used in > one effect. Memory for these entities is a much less important > consideration. > > Both methods have their advantages, but my opinion using linked lists for a > particle engine is much superior than using an array. Variable memory usage, > speed during allocation, and most importantly, simplicity more than make up > for the lost speed during deallocation. > > ----- Original Message ----- > From: "Iain Farrell" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 27, 2002 8:55 PM > Subject: Re: [hlcoders] Particle System > > >> ----- Original Message ----- >> From: "Miguel Aleman" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Thursday, June 27, 2002 11:04 PM >> Subject: Re: [hlcoders] Particle System >> >> >> Look Scott, if you don't have the time to enter this argument then simply >> don't. That must of been the most arrogant comment I've heard this week. >> >> ------ >> he wasn't trying to be arrogant, he was just saying (basically) "I can't >> argue my point fully, because I am busy with other things (probably things >> we want him to busy with)" >> His point was simple though - you don;'t need a potentially infinite > number >> of particles, so link lists aren't necessarily the best answer (especially >> when you may have to take into account slower machines) >> I gather from his post, he's trying to say you should try and estimate the >> max. number of particles you'll need and use an array for that amount. >> you may be wasting memory, but on slower systems the sped increase may be >> more beneficial >> >> >> ICQ : available on request >> >> "That's it - screw CNN, from now on - I'm going to rely on Porn sites, >> for news...." -=[Clawz]=- in alt.games.half-life >> >> HL Mod Site : http://www.tfhl.net >> AGHL Geek Code: >> 78 M D T+ C- A+ Ca H+ K P S+ B Po* RGB+ I++ L3++++++ Sp- ICQ@ >> >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, > please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
