> Yes, that is exactly what I'm planning to try next. And its not really > about performance (I wouldn't choose Python in that case). It is more > about finding best way to express ideas in code. I am not sure yet, > but it *feels* more natural for me to control particle state in its > drawing routine. Time will show. This whole thing is just a test bed > for my humble gamedev ideas.
Actually, I would argue that it is more natural to separate the update from the drawing code. The drawing code just shows you the state of the system at a particular point in time, while your update code should account for the true time between updates. By the way, I built a particle emitter using small textures (instead of simple points) and a numpy array to store the vertices, and I was able to get about 1000 particles on my powerbook 1.25 GHz machine (using glVertex pointer commands) - here's a picture showing a overall particle manager with a bunch of particle emitters: http://rabbyt.googlegroups.com/web/particle.png (the snapshot doesn't do it justice - the bottom three emitters zip back and forth across the screen). Also, some newer graphics cards have support for billboarding, which let you use a texture while only having to specify a single vertex point per particle (and the billboard is automatically aligned with the camera axis, so you can use it in 3D without having to do complex inverse view matrix transformations). Naveen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
