First time particle engine (Java / LWJGL)

Ok there are two things to have a look at, first the software design and second how u used the graphic API (here OpenGL).

SW:
API:

Also very important you aren't sorting your particles which give u wrong results if not additive blending, what u aren't using.

ps: pls use milliseconds to messure your perfomance and not FPS, because this metric is a lot more comparable(i.e. 20->40 fps is a much higher speedup then from 120->140FPS)

Ok there are two things to have a look at, first the software design and second how u used the graphic API (here OpenGL).

SW:

I noticed several points.

general:

• use the standard Java naming convention pls (upper case Classes)
• don't use inner classes
• use data classes like vectors for position, velocity & color)
  about your desgin
  
  • am I right that each particle is creating his own Thread just to know what time it is? Just do the update with a given delta time.
  • I would put the update logic in the particle container(ParticleEngine) not in the particles. Or create a particle interface so each particle can have its own update function, but with this u can't have interaction between particles.
    

API:

I see u are using OpenGL 1, it would be way faster using Buffer Objects for the particles.

Also very important you aren't sorting your particles which give u wrong results if not additive blending, what u aren't using.

ps: pls use milliseconds to messure your perfomance and not FPS, because this metric is a lot more comparable(i.e. 20->40 fps is a much higher speedup then from 120->140FPS)

Thanks for the reply. My fps is measured like this...



public void dofps() // calculate fps
{
iFPS++;
if(fpsTimer.getTime() >= 1000)
{
//iFPS = (int)(lTotalFrames / (frameTimer.getTime() / 1000));
//System.out.println(iFPS);
iAvgFPS=iFPS;
iFPS = 0;
fpsTimer.startTimer();
}
//This is only called when the game runs "draw()" which is only "drawing" stuff.

The game loop is...




private void run() // the game loop
{
bIsRunning = true;
double next_game_tick = lCurrentTime;
while(bIsRunning && !Display.isCloseRequested())
{
if(!dotime())
{
break;
}
int loops = 0;
while(lCurrentTime > next_game_tick && loops < 10)
{
update();
next_game_tick += 10;
loops++;
lTotalFrames ++;
}
draw();
dofps();
}
bIsRunning = false;
destroy();
}

public boolean dotime() //calculate time for the frame, also determine if time hacking
{
lCurrentTime = System.currentTimeMillis();
if(lCurrentTime >= lTimeStarted) // current time should always be larger than time started, or player is time traveling O_o
{
lTotalTime = lCurrentTime - lTimeStarted; //keep track of time... accurately
return true;
}
else
{
ErrorClass.ReportError("You are time traveling!"); //back to the future
stop(); return false;
}
}



so yeah i'm actually getting 1000+ fps from what I can tell.

My timer class just returns a subtraction operation...



public long getTime()
{
if(!bStarted)
{
return -1;
}
if(bPaused)
{
return lTimePaused;
}
return (Game.getCurrentTime() - lTimeStarted);
}


and game object is public static final (so there's only one) and getCurrentTime() just returns a variable.

May I ask why you think you need a better random function? Also, define better.


Concerning style I agree with Danny02, and here's a few more tips:

- Rename ParticleEngine to ParticleEmitter, it's more descriptive of what it does.

- Don't create a timer for every particle. It causes a lot of duplicate calculations, and wastes memory. Particle systems is one of the areas where this can really matter. Pass the update time as a parameter to the 'update' method. This also makes it easier to control the update speed, which is useful for things like pause and slow motion.

- Use floats instead of doubles in you non-OpenGL code, unless you really need their precision. Always avoid doubles in your OpenGL code.

- Remove the 'if(daddy.randomcolor)' branch from the particle constructor. Pass the color to the constructor, or add a method to ParticleEngine which returns an appropriate color.

- Remove the null check from your ParticleEngine update loop. There are two things you can do, depending on how 'clean' you want your code to be. The clean solution is to remove dead particles from your particles array, and add new particles later. The other option is to re-use instances, which may be faster depending on some other factors, but is more error-prone. (Not using a particle class at all is a good option too, but I won't get into that now). Either way, you should keep all living particles in the first part of the array, and the dead at the end. Remove the particle 'dead' member. The kill method will look something like:

numberOfLivingParticles--;
particles[indexOfParticleToKill] = particles[numberOfLivingParticles];
particles[numberOfLivingParticles] = null; // If creating new particles, or
particles[numberOfLivingParticles] = particleToKill; // if re-using instances


- Remove the alive/dead branch from your update loop. Branching in tight loops should be avoided. If you keep the particle array sorted, the update function can look something like:

for(int i = 0; i < numberOfLivingParticles, ++i){
// Update the particle i. Keep in mind that if the particle removes itself during the update, the particle
// copied over the current particle will not be updated this frame. Usually not a problem, but if it is that should be easy to fix.
}

for(int i = numberOfLivingParticles; i < sizeOfParticlesArray; ++i) { // Or spawn x particles per second.
// make new living particles, depending on if you're creating new instances or reusing them.
}


Please let me know if you have any questions.

EDIT:
I forgot, if you want meaningful data when measuring performance, simulate enough particles to stress your system. Go for an update time of about thirty milliseconds.

May I ask why you think you need a better random function? Also, define better.


Concerning style I agree with Danny02, and here's a few more tips:

- Rename ParticleEngine to ParticleEmitter, it's more descriptive of what it does.

- Don't create a timer for every particle. It causes a lot of duplicate calculations, and wastes memory. Particle systems is one of the areas where this can really matter. Pass the update time as a parameter to the 'update' method. This also makes it easier to control the update speed, which is useful for things like pause and slow motion.

- Use floats instead of doubles in you non-OpenGL code, unless you really need their precision. Always avoid doubles in your OpenGL code.

- Remove the 'if(daddy.randomcolor)' branch from the particle constructor. Pass the color to the constructor, or add a method to ParticleEngine which returns an appropriate color.

- Remove the null check from your ParticleEngine update loop. There are two things you can do, depending on how 'clean' you want your code to be. The clean solution is to remove dead particles from your particles array, and add new particles later. The other option is to re-use instances, which may be faster depending on some other factors, but is more error-prone. (Not using a particle class at all is a good option too, but I won't get into that now). Either way, you should keep all living particles in the first part of the array, and the dead at the end. Remove the particle 'dead' member. The kill method will look something like:

numberOfLivingParticles--;
particles[indexOfParticleToKill] = particles[numberOfLivingParticles];
particles[numberOfLivingParticles] = null; // If creating new particles, or
particles[numberOfLivingParticles] = particleToKill; // if re-using instances


- Remove the alive/dead branch from your update loop. Branching in tight loops should be avoided. If you keep the particle array sorted, the update function can look something like:

for(int i = 0; i < numberOfLivingParticles, ++i){
// Update the particle i. Keep in mind that if the particle removes itself during the update, the particle
// copied over the current particle will not be updated this frame. Usually not a problem, but if it is that should be easy to fix.
}

for(int i = numberOfLivingParticles; i < sizeOfParticlesArray; ++i) { // Or spawn x particles per second.
// make new living particles, depending on if you're creating new instances or reusing them.
}


Please let me know if you have any questions.

EDIT:
I forgot, if you want meaningful data when measuring performance, simulate enough particles to stress your system. Go for an update time of about thirty milliseconds.

Thanks for your reply,

I'm not sure I understand the timing problems you mentioned...

If each particle doesn't have its own timer (which is honestly just a few long variables), then how can each particle have its own unique start and end time?



class MyTimer
{
long timestarted = 0;

MyTimer() {
timestarted = Game.getCurrentTime();
}

void starTimer(long time) {
timestarted = time;
}

long getTime() {
return Game.getCurrentTime() - timestarted;
}
}

class Particle
{
MyTimer timer = null;
long lifespan = 1000;

Particle() {
timer = new MyTimer();
}

public boolean getIsDead() {
if(timer.getTime() >= lifespan){
return true;
}
return false;
}
}

What is wrong with that implementation? It's basically what I have....

and since this post, I rewrote the emitter to just re-use particles.

here's a video of it in action with vsync enabled

The video looks nice, how many points are that?

Making the update time a parameter of update gives you a lot of flexibility, like a variable time step so the game runs fine on slower systems and control over the speed of the animation (the slow motion effect I mentioned). Pausing the game can be a problem with your current approach because it looks like you use a single source of time info for every system in the engine (Game.getCurrentTime()). If every system in the game uses this as a source for the current time, you can't pause the game but animate the buttons of an overlay menu in an easy manner. Specifying the update time yourself allows you to use different timers for different parts of the game.

A simple way to handle the life span of your particles is keep a single float member called lifeTime or something similar, which keeps track of the time the particle has left until it dies. In update, all you have to do is:

if(lifeTime <= 0.f) {
killParticle();
}
lifeTime -= timePerFrame;


You can use the same method with longs/ints too, if you wish.

The video looks nice, how many points are that?Making the update time a parameter of update gives you a lot of flexibility, like a variable time step so the game runs fine on slower systems and control over the speed of the animation (the slow motion effect I mentioned). Pausing the game can be a problem with your current approach because it looks like you use a single source of time info for every system in the engine (Game.getCurrentTime()). If every system in the game uses this as a source for the current time, you can't pause the game but animate the buttons of an overlay menu in an easy manner. Specifying the update time yourself allows you to use different timers for different parts of the game.A simple way to handle the life span of your particles is keep a single float member called lifeTime or something similar, which keeps track of the time the particle has left until it dies. In update, all you have to do is:if(lifeTime <= 0.f) { killParticle();}lifeTime -= timePerFrame;You can use the same method with longs/ints too, if you wish.

Thanks! The animated quads is 200 quads (my system was handling 2000 at one point). and the Points is 9000.Also, thanks for your ideas and contributions. I am going to try and wrap my head around your optimizations. I do not intend in any way to use this system I have wrote for use in an actual graphics engine. I just wanted to see if how I thought particle systems worked was the actual way that they work.

Also I dont think you understand how my timer works. because I can pause anything on the screen, including individual particles.