That isn't possible without more invasive surgery, CEG's do not keep track of particles after they're spawned (so slaving their positions to that of the projectile during subsequent frames requires a bit of administration code that I wasn't interested in writing Wink).
@Kloot:
Yeah, but I'm pretty sure that, in terms of efficiency, it'd be well worth it. The big CPU hit with these systems is the number of systems that are "alive" per game frame... not the particles who are acting out their deterministic math per frame. I don't know why this is- I assume it has something to do with reading all of the data into the system and creating the initial model in memory, but I'm too stupid to know how that works at the deeper levels- I just know that I can create hundreds of particles from one system, and it's significantly faster than a series of co-existing systems which together produce fewer particles. I don't have firm math on that, or anything, but it's roughly 2/3 to 1/2- it's a big hit, in terms of performance. So, if the CEG stayed "attached", it'd run significantly faster, even with the same total particle-count.
Lastly, while I have your attention, I should also mention two more things that favor a millisecond, desync timing model:
1. People could de-syncronise their particle systems by a millisecond or two, so that the CPU hit would be distributed over larger amounts of time... while Spring is using the CPU between game frames, it's probably using far fewer cycles at the tail ends, frankly.
2. I've had to do a bunch of funky, mathematically-complex stuff with that missile trail, to make it work that well, forcing me to use a CSimpleParticleSystem. If I could call the CEG every 5-10 milliseconds instead, I could just use a HeatCloud, which has maybe half the CPU impact... oh, wait, duh, HeatCloud doesn't support ColorMap <slaps self>
@Warlord:
The CPU hit is significant- you don't get eye-candy like that for free. It's not awful, mind you, but I wouldn't want to see 50 of these all firing at once.
How nasty it is depends on a lot of factors, however, which is why I keep talking about the issue of timing- like far too many things in Spring, everything in CEGs happens exactly every 1/30th of a second, and there aren't any ways for game designers to spread that out and distribute the load. In COB, we're allowed to do that, which is why most of the animation code I write has small randomization, even in cyclic stuff, like walk-cycles- even a millisecond is practically forever, for a modern CPU, and why make everything pile onto the first millisecond of a 33-millisecond slot of time?
