Good idea but i think your approach is not the best. I guess you use the this system only to decide if you create a new particle - after you have spawned them you dont reduce them if necessary, but let them life till the end of there normal lifetime?
You cant wait for them to die...then they will all be dead at the same time by the time it can regulate a new batch.
This actually makes the inconsistancy worse, and pulsing noticable in short burst too.
This causes two problems:
- generally your spawning is very pulsating, cause you spawn points, than system slows down, then you dont spawn to increase framerate, which leads to a gap in your particle stream but give you more time to spawn new particles later again - so your framerate jumps every few secs and your particle stream pulsates, compare the to attached images to see what i mean.
You wont even see this pulsating because typicall emitters only last a few seconds with explosions.....this test is constant, thats only reason you notice it.
- calculation the particles in background is faster than finally drawing them. This causes the problem, that when you look in an area with only a few visible particles, you spawn many particles in background. If you then fast turn and look in an area with many particles, you have there so many particles that displaying them slows you down below 10fps for a few secs (till the particles die).
Calculating 150k particles is still too much work no matter what, rendered or not.
I think you should think about implementing a simple maximum particle count (that can get changed by the user). Then you just need to find a way to take care that you spread the max number of particles over all emitters and still cause a constant stream of particles. And a way to kill active particles even before there end of lifetime could be needed too.
Believe me, when you are using alot of explosions and if 150k fast living particles fire off at once, you wont notice any problems....theyll be dead by the time any pulsating starts.
This is a constant 150k particles...of course youre going to see an issue.
That was the point of initiating 150k of them to regulate a cornercase, which you will likely never see anyhow because of how quickly itll last in time.
As a programmer if you overlook something and this cornercase happens.....your game wont stop...particles will be expended instead, and you can go fix it later....its not intended to regulate particles not at all! Its intended to prevent performance issues during a cornercase.
I hope i dont sound harsh, im not trying to be. Honestly i believe i captured this cornercase perfectly, the quality of persitant particles wasnt the focus, rather the opposite.
You know as well as i do, quality and performance are interchangable.
Always one at the cost of another, and in this case i captured the best quality possible....other options like you mentioned really looked worse, especially if you wait for particles to die and prevent new births...this causes an iregularity in timing, even with a "template of time segments", the pulsating gets worse due to the "waiting to die" and "waiting to be born".
My point is this....this "feature" is not to make your game look better, nope not at all. You must NOt depend on this feature to "save the day". You must be wise and use limited amounts of particles right from the start. And if for whatever reason your game is running slower than expected, the APE will cut losses and prevent sucking up all your resources.
