I understand one needs to sort particles back-to-front (if they have alpha values).
Does that mean that if i have a thousand sparks and a thousand smoke particles I need to switch my renderstates each time another type is in front?
In worst case that means 2000 times changing my rendering parameters (in best case 1 switch), which sounds pretty bad, but I guess it’s the only solution right?
This is very complex problematic. You mostly can´t afford to do that on CPU. One of most modern approaches for that is following: GPU state aware particles using vector surfaces (textures) for data that are being sampled in vertex shader. This kind of particles allows for instance collisions and such a things. There is way how to sort them on GPU over time using algorithm that has high coherency (doesn´t cause blinking and while all particles aren´t being sort on single frame it is pretty efficient method).
I definitely suggest to dive deeper in that topic as this kind of particles is one of most advanced and efficient. To some degree this allows to get advantage of point particles which normally requires Geometry shader to which we don´t have access yet in monogame.
Some sources (tho go for google in anycase):
My favorit: GPU Gems http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter46.html (thank you Nvidia)
http://www.gamasutra.com/view/feature/130535/building_a_millionparticle_system.php?print=1
You could do it by first, sorting particles by their emitter position.
If sparks are “blend added” they dont need to be sorted at all in their own emitter.
I think it would result in less work than recoding all your particles system.
that’s basically the way I would go. I have many types of stuff I need to blend and I don’t think having geometry, particles, trails etc. sorted on the GPU is feasible. Maybe with computeshader it was.
So yeah, I think I’ll go the sort by emitter route