You forgot the end; your code won't run. 
Well a particle system really just a bunch of objects playing the part of a single sprite or image that will go a pre-determined path and last only so long, usually termed 'life' or 'time-to-live.' As it's life fades or comes near it's end, so will it's visibility or alpha value. A single sprite, or 'particle' shows this effect well, but isn't really all that attractive, however when done in a big or small group together can make up many effects which can look quite nice and sometimes life-like. The higher the amount of particles the more effective or interesting the effect, however the more processing power it requires.
Essentially what you are doing in your code is making an object class or record type to track a single particle. You then make make an array or list of these so that you can keep track of as many of these as you require. Usually this will be the main part of your particle engine's code.
Your particle class will look something like this...
Code:
type
TParticle = record
X, Y: Real; // Location
VelX, VelY: Real; // Movement
Life: Cardinal; // Time to Live
rr, gg, bb, aa: glUint; // Color information with initial Alpha value
end;
Now I used the gluint type from OpenGL which is just an unsigned integer type. You'd usually have some kind of color information if you are using white sprite textures or if you are just using pixels, but it's more common these days to have even just a simple small texture that you can color as you need. Also I used a record type to simplify the structure a little. You can use class(TObject) if you wish to make yours object oriented if you prefer.
You'd then make your array or list, also called emitter, that will contain all of the particles that you would need and the stuff to make it all display, time out, etc. For example...
Code:
type
TEmitter = class(TObject)
NumberOfParticles: Cardinal; // Keep track of how many particles you are using!
Particles: Array[0 .. 255] of TParticle; // You're lovely little particles
Sprites: TTexture; // stores texture or reference to the texture you're using
constructor Init; // may include code to init your particles
destructor Deinit; // will include code to free your list to prevent memory leaks
procedure Update; // performs movement and time to live countdown on particles
end;
Now this part really will be what controls all your effects and how each particle will behave. You can make it as complex or as simple as you feel you need. I've left out a bunch of other possible functions, such as particle list/array management, detection of dead particles and so on. I won't go that deep in my explanation here.
Update; would be the main function of your emitter. It changes the position of ALL of your particles by using their X,Y and VelX,VelY values and reduces your life value by it's increment (would be 1 in this example) and would also reduce your particle's alpha value based on it's time to live. (However you choose to translate this from your life value to your alpha.) You want to run this procedure once per iteration of your main game loop.
That's a very basic intro to particles as I know them. Others will be able to help you more and even show you much more complex systems that you can try. I'd recommend not getting too carried away unless you plan on only higher-end systems being able to run your programs visual effects. Otherwise particle systems can be kinda fun to play with. I've made a somewhat simple one myself for one of my games before and it really did add to the visuals.
Reply With Quote
);
or OpenGL
Originally Posted by JSoftware
You could use only pixels and alter the color of them from it's base color to the background color of your screen to give the illusion of fading out. You then will have to sort your particles drawing order by life remaining to prevent the majority of a distorted effect. That's considering you are just using a single background color, which might not be the case. Still, OpenGL or D3D are your best bets. OpenGL is my personal favorite so I would of course recommend it, especially since SDL games and programs are more easily adapted to use OpenGL instead of DirectX. (You can keep using your existing window management, input and audio code for example.)
Bookmarks