I've been searching like a bloodhound through forum archives for some working source code of a particle explosion. Does anyone think they could point me towards a tutorial or just provide some code directly? I'll keep searching but I think human's understand what I'm looking for better than the search algorithm does.

Create a particle struct or class containing x, y, vel, dir, color. Array or vector containing the amount of particles you want in the explosion.\ When explosion happens For each particle give particle random dir give particle a vel After explosion happens For each particle update particles position (calculate xS and yS from vel and dir)

Blargmob's basic approach is good, though I'd recommend that you dispense with the array and just simply maintain a big list of "graphical objects" in your program, all of which can have individual velocity, acceleration, lifetimes, and so on.

In my recent projects, having every sprite/etc. on the screen be considered a "Particle" and treated the same has simplified rendering and updating significantly, at the expense of slightly more memory and CPU usage (that is not an issue at all on a PC built this century).

If you use the hardware accelerated approach, blargmob's method is better, since you don't have to switch textures between each particle, leading to enormous speed benefits.

You could look at the sources of these demos I guess.

That's assuming all of your particles in the system are the same texture, and your "big list" isn't optimized to provide similar benefits.

In my case, neither of those assumptions are true, but I agree, mileage may vary.

I appreciate your replies, but I have to admit that I don't know what you are all talking about.

I tried the sources of the demos you provided a link to, but they are all way to complex for me to understand with my limited knowledge of this particular aspect of programming.

Is it difficult to write the code for a simple explosion? I learn best from working code. I heard that there are simple examples somewhere, but I haven't been able to locate them.

Thanks again for all your help so far.

I think you'd learn even better by trying. Write some thoughts down on how you think it would be done and then try to code it yourself. When you get stuck at this point, then come here and show your work.

First learn what we say. Then try to code it.

Thanks for the advice, but I'm still going to go with learning by example.

I believe the phrase goes something like, "Why reinvent the wheel?"

I'd really appreciate it if someone would post something that I could learn from. I want to learn. I want to.........LEARN!!! :p

Try something like this.

I didn't test it, but that should get you started. If you want images attached to your particles, you may not need oldx or oldy, they're just for drawing the line.
Correct me if I'm missing anything, but I think this code needs to include allegro.h, ctime, math.h, and vector.
Let us know how the learning goes!

And a good way to learn is by doing... Blargmob gave you an algorithm you could implement in your very first reply. Translating it to code shouldn't be too difficult if you just try. Here's an example based on his algorithm (untested, uncompiled) :

And a quick example of usage :

(*p).x = (*p).oldx = x;

perhaps going p->x = p->oldx = x; would actually be clearer.

Edit:
Memory allocations are quite expensive, so you could use an array. If the array is full and you need to insert a new particle, you can over-write the oldest.

Particles lend themselves to C++, with a pixel class, but I did my example in C. You could easily roll this up into a class, but I am in a C mood. (The code, binary and code::blocks project is attached.)

Why use malloc when you're using c++, why use doubles? you don't seem to have the ability to end the life of a particle, or group particles together as distinct units, or reuse the memory for new particles.

Because it's a simple example, I didn't include anything for deleting particles, but you could easily give each particle a lifetime and do something like this:

What would you recommend for my example other than malloc? I'm still working with my first project that uses structures, so I'm still quite new to the various uses of malloc, new, free, and delete. You should be able to malloc or new a structure, right?
As for the doubles, feel free to use floats. That would take up less memory, right?

The thing is new and delete are part of C++, that is memory allocation and freeing are part of the language, when in C (malloc and free), they are provided by the system library.

When you use new it calls that class constructor if there is one, and delete calls the destructor. If new for some reason can't allocate the memory, the default action is to throw an exception, where malloc just returns a NULL pointer.

You can use malloc to allocate an area in memory for a struct, but you can't really use it to create a class on the heap.

(AFAIK you can use malloc, then manually call the constructor, then manually call the destructor before freeing it, but you are really asking for trouble if you go down that path.)

Edit:
and please for the love of whatever deity you follow, use -> to dereference your pointers

I think there's a little miscommunication in this thread... as to the skill of the original poster (Op).

Not taking in account sound and keyboard input.. this is how I (self taught game dev) learned:

1-Create a program that draws a rectangle.
2-Then try to change it's color.
3-Then try to change it's color rapidly with a loop.
4-Once you've got that then try to move it.
5-Then try to make it bounce off the edges of the screen.
6-Then fiddle around with random ideas like "What if I make it change color everytime it bounces?"
7-Then make an array of rectangles so you have 20 or more bouncing off the screen.
8-That should give you enough working knowledge to write your own particle explosion, starfields, etc.

I'm curious, which step is the OP at? :p

What is the specific task the OP is having trouble with?

Idealius: your example fails. It took me less than a day to learn how to bounce rectangles around on the screen. Ok, I used circles instead of rectangles, but it's the same thing. A particle explosion is much different.

You're probably right as I learned on Qbasic long before Allegro ever existed..
And computers were less mainstream back then, too.

I guess I'm just wondering if the OP has a basic understanding of arrays. Once you have that a particle explosion should be easy to create.

Of course creating, tracking, and deleting it as an object is another layer of complexity..

kudos to circles =)

I learned in QBASIC too!

My biggest problem with a particle explosion was always the random direction thing. I could make things go up, down, left, right, or at a 45 degree angle to any of those, but it wasn't until just recently that I learned how to make things go in any direction. I still have trouble with particle effects, though.

Oh cool. I guess I just assumed you started on Allegro.

Yeah I think I bridged that gap by using float's instead of int's for the particle's coords and deltas. And of course knowing how to make a random value that can be negative OR positive helped, too..

Then there are more complex ways to do it, by giving the particles' starting points based on the shape of a circle so when they travel the same basic circular plot is maintained.. like fireworks.

..using vectors (not the class)..etc. Ah memories. Thanks..

I began working with 2d environments a little over 2 weeks ago. Before that, it was all text, learning for and while loops, arrays, etc, etc, all the basics. I'm still not that familiar with implementing physics for objects in 2d. I made a bouncy ball program but I'm pretty sure I cheated.

I'd say I'm probably around step 5.

I'm going to try out some of the examples posted here, although I can already tell that it may be difficult for me to understand. I'll post back later with how I did.

Thanks for all the replies! I woke up this morning and was like, "Whoa! 17 replies!!"

----------

I can't seem to figure out how to add a post right after my last post, so I'm just going to use the "minus bar" and edit this post.

Schyfis, I tried out your code and I threw together a working program below (oh yeah, I don't know how to put it in a cool code window). I'm a little confused about it though, mainly this line:

particle* p = (particle*)malloc(sizeof(particle));

This allocates memory for each particle in the vector, am I right? But, why is it necessary to do this? Is it because particle p has been declared as a pointer? And if so, why not just directly declare p as not a pointer? Full working program below:

#include <allegro.h>
#include <ctime>
#include <math.h>
#include <vector>

using namespace std;

BITMAP* buffer;

//define a particle structure
typedef struct particle {
//we'll need an x and y position for each particle
int x, y;
//the particles are going to be moving,
//so here's x velocity and y velocity
int xvel, yvel;
//let's also keep track of the old
//x and y positions so we can draw the
//particles as lines instead of just points
int oldx, oldy;
};
//create a vector of pointers to particles (kind of like an array)
vector <particle*> particles;
/*
explode: a function to make a particle explosion
parameters:
x: the horizontal position of the explosion's center
y: the vertical position of the explosion's center
num: number of particles in the explosion
*/
void explode(int x, int y, int num) {
//initializes the random number generator with the current time as the seed
srand(time(0));
//for loop to create num particles
for(int i=0; i<num; i++) {
//allocates memory for our new particle
//note that this is a pointer to a particle, not the particle itself
particle* p = (particle*)malloc(sizeof(particle));
//set x, y, oldx, and oldy to the center of the explosion
(*p).x = (*p).oldx = x;
(*p).y = (*p).oldy = y;
//set xvel and yvel to random numbers between -4 and 4
(*p).xvel=rand()%64-rand()%64;
(*p).yvel=rand()%64-rand()%64;
// (*p).xvel=-1;
// (*p).yvel=0;
//add the particle pointer to our vector
particles.push_back(p);
}
}
/*
stepParticles: a function to step the particles through one frame of movement
parameters: none
notes:
-call this function every time you go through your game loop.
-remember that particles is a vector of pointers, so you have to dereference them!
*/
void stepParticles(){
//iterate through our vector of particle pointers
//particles.size() gets the total number of elements in the vector
for(int i=0; i<particles.size(); i++){
//set oldx and oldy to the current values of x and y
(*particles.at(i)).oldx=(*particles.at(i)).x;
(*particles.at(i)).oldy=(*particles.at(i)).y;
//now we add xvel and yvel to x and y so the particles move
(*particles.at(i)).x+=(*particles.at(i)).xvel;
(*particles.at(i)).y+=(*particles.at(i)).yvel;
}
}
/*
drawParticles: a function to draw the particles on the screen
parameters: none
notes: call this function every time you go through your game loop.
*/
void drawParticles() {
//iterate through the vector like last time
for(int i=0; i<particles.size(); i++){
//you'll have to have a BITMAP named buffer for this to work,
//assuming you're double buffering
line(buffer,
(*particles.at(i)).x, (*particles.at(i)).y,
(*particles.at(i)).oldx, (*particles.at(i)).oldy,
makecol(255,127,0));
//it spans many lines to make it easier to read
}
}

int main(){
allegro_init();
install_keyboard();
set_gfx_mode(GFX_AUTODETECT_WINDOWED,640,480,0,0);
set_color_depth(32);

buffer = create_bitmap(640,480);

// particle.x = 200;
// particle.y = 200;
// particle.xvel = 5;
// particle.yvel = 5;

//an example of your game loop
while(!key[KEY_ESC]){
clear_keybuf();
if(key[KEY_SPACE]){

srand(time(0));
//make explosion at random place on the screen
//explode(rand()%SCREEN_W, rand()%SCREEN_H, 5);
explode(300,240,100);
}

clear(buffer);
stepParticles();
drawParticles();
blit(buffer,screen,0,0,0,0,buffer->w,buffer->h);

rest(20);

}
}
END_OF_MAIN();

To put code into the codebox just put [code] and [/code] around it.

The particles are declared as a pointer so they can be allocated on the heap(correct me if I'm wrong). This way they can be deleted. The stack is what items are declared on if you don't allocate memory, and it is hard to delete them off of it. The stack will also go out of scope. Ex:

int* return_stack(void)
{
   int number = 10; //declare on stack, valid now
   return &number; //return address of number
};

int main()
{
   int* p_num;
   p_num = return_stack(); //number goes out of scope,
   printf("%d",*p_num); //causing p_num to be some random value
}

The heap is where memory that was allocated by malloc or new resides. It doesn't go out of scope Ex:

int* return_stack(void)
{
   int* number = (int*)malloc(sizeof(int)); //declare on heap, valid now
   *number = 10;
   return number; //return address pointed to by number
};

int main()
{
   int* p_num;
   p_num = return_stack(); //number doesn't go out of scope,
   printf("%d",*p_num); //causing it to stay 10
   //deallocate it (forgot the code)
}

Always be sure to deallocate memory or there will be a memory leak.

Thanks someone972, for showing me how to do the code thing.

By the way, what's a memory leak?

I'll play around with the particles for a while a post back if I run into more trouble with it. Thanks for all the help everyone!

Memory leak occurs when allocated memory is not freed when you're done with it.
Example relevant is when you keep creating more particles but never free any, then the old particles stay in memory, and when you have reused the the old pointers to point to the new particles you have no way to access the old particles, they have leaked out of your control.

Whenever you allocate memory, either using malloc (plain C) or new (C++), you are putting your hands around a bit of memory that can't be used for anything else. It is good practice to deallocate anything you allocate, either using free (plain C) or delete (C++). Most OS (that is, I believe it is the OS that does this), deallocates memory on the program's exit. However, it's still good practice to do it yourself, and if you are allocating memory for things that only exist for a moment in your program, you are wasting memory and this can cause the entire computer to run out.

Thanks for the explanations. I understand memory leaks now.

I managed to make a little explosion too. I'm quite proud of it. I'd probably use it in combination with an animation of an explosion in the center.

I get this warning whenever I compile, I know it's because I'm passing doubles to putpixel() but I don't know how to fix it.

[Warning] passing 'double' for converting 2 of 'void putpixel(BITMAP*, int, int, int)'

That is an awesome particle explosion! Also, the code is easy to understand even without the blue little helpy helpers.

I make my code easy to understand because the more compleximacated stuff makes me think. And I'm too damn tired to think right now.

Neil: It runs too fast on my q6600 quad core. It seems even if you didn't program it for multi core systems, X gets its own core as well

SILENCE!

I was too lazy to implement real timing... would it work right if I used timing instead of rest()? If I had it in a game I'd do it properly.

Heh, I'm just bugging you.

C++ uses strong static typing, which means that you need to pass arguments with the correct types.
Some implicit conversions are allowed (i.e., you can assign a value of type A to a variable of type B), but if the conversion can lead to loss of precision (e.g. double -> int), the compiler throws a warning. You need to explicitly cast to tell the compiler that you know what you're doing:

putpixel(buffer, (int)Particles<i>.x, (int)Particles<i>.y, makecol(255, 255, 255));

Note that this produces a sub-pixel inaccuracy around 0, because the default cast rounds towards 0 (negative numbers round up, positive ones round down). Objects crossing the x or y axis will experience a tiny glitch. You can use libm's floor() function to avoid this:

putpixel(buffer, (int)floor(Particles<i>.x), (int)floor(Particles<i>.y), makecol(255, 255, 255));

Type system war!!!! :-)

C++ has a weak static type system, due to static_cast, reinterpret_cast and C-style casts.

And what if those casts didn't exist? I figure much worse...