I made a pretty extensive particle system using a combo of Dark coder and GG's shader particles POC's.
The nature of this method to produce particles includes a vertex cloud made up of an object created in a memblock (or other way).
In the shader each vertex is "decoupled" to produce it's own (internal to the gfx card) plane that is aligned to the camera.
The UV coordinates of the object used are irrelevant in the Vertexshader when it comes to positioning the texture on the "internal" camera aligned plane(s).
To rotate and/or atlasanimate the texture it has to be done in the Pixelshader.
Have to say the pointsprite method is now pretty arcane and i recommend not using it due to both the problems with different graphics card drivers making it hard to get a consistent result. And that the gfx optimizations making the six vertex plane/particle now render as fast as the pointsprite planes.
Elaborating on the (dire) gfx driver issues. When i was full up in this project i noticed from one day to another particles behaving very strange indeed. What had happened was the NVidia drivers update i installed had changed the internal check of the vertex positions close to the cameras XYZ (0,0,0) position. Particles that should go past and behind the camera "slided" 90 degrees past the camera. I then had to make my own clipplane in the shader.
However this method is pretty efficient as I could run over one million atlasanimated and rotating sprites with only a couple percent CPU usage, the 9800 gfx card i had managed ~100fps but it was at max utilization.
This post I made in the Shader thread shows the shader I used (this is a older version, i later made the rotation transformations in the VS):
http://forum.thegamecreators.com/?m=forum_view&t=91453&b=1&msg=2162382#m2162382
In the PS you'll see how the rotation is done with the TEXCOORD0 output UV's.
You have to keep in mind that each object you use should be considered one particle emitter. You could have multiple texture stages to the object and have a emitter with different particles but i only used one texture per emitter.
I used a internal shader loop to enable fifty simultaneous emitter (objects) to be used with one shader. Don't even think of loading one shader per object.
One thing i never finished though is the overlap in a texture atlas when rotating.
Imagine rotating a square 45 degrees over another square, the corners of the rotated square will overlap outside the edges of the nonrotated square. What will happen is the texture image corners in the adjacent tiles in the atlas will show up on the one displayed. I solved it quicks and dirty by shrinking each separate image on the atlas by sqrt(1) before combining the sequences to a complete atlas image.
Regards