Particle design in Slick

Engines, Libraries and Tools
#1

Hello!

I’m making a very small eye-candy-thing because it’s vacation!
I have about 10 entities on screen at all times, and all of them need several emitters. The problem is that my entities die in a matter of 1 second or less, and then a new one gets to live instead.

Should I have a particle system in each entity, or a global one which has emitters for all the entities?
I’m worried the particle systems would take too long to make, so that my entities die before the particles are up and running.

I’m ofcourse loading images for the particles beforehand, so they’re in the memory.

#2

Reading this makes me feel more like a noob than ever before :frowning:
I have no clue what anything you said meant. Is there anywhere to learn this sort of stuff?

#3

Hey.

A couple of questions :slight_smile:

How do your entities die, and new ones created? (Does the dying entity spawn the new one, or are the dying/new entities unaware of each other?)
Should the emitters keep their state from entity to entity? (Once Entity A dies and is “replaced” by Entity B, should the particles emitted by emitters on Entity A dissipate immediately, or should their state be kept in Entity B?)

#4

There are alot of tutorials on Particle Systems on the web. One of the more (in)famous tutorial site on OpenGL stuff is Nehe.

Lesson 19 explains a basic particle system.

http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=19

#5

A new entitiy spawn each second. They go around for a bit, and when they hit a specific line they die instantly. So they’re very unaware :stuck_out_tongue:
It’s firework actually, I need an emitter for the explosion, and the tail of smoke they draw on the sky. I think I’m going to kill the emitters together with the entity… The question is, if it’s too time-consuming to make particle systems and kill them so quickly… (Each entity lives 0.5 sec - 5 sec.)

#6

I’ve seen an implementation where the ParticleSystem was global ( for each kind one PS ). Entities get their Emitter(s) from the ParticleSystem and add them when they die. There should be a copy method in ConfigurableEmitter, so you don’t need to load from the XML-File again and again. Works pretty well in Slick. Hope this helps :slight_smile:

#7

You could go for a global Particle System that has a list of entities. Each cycle, the particle system iterates over its entities, and updates their effect. Entities could have some kind of reboot/reset method, so that the particle system recycles the same entities instead of constantly adding/removing new ones. If you have multiple variants of entities (different kind of fireworks), you could perhaps set the entity’s behaviour from some static context when they reset?

If you have a ParticleBehaviour class (or something equivalent), subclassed for different kind of fireworks, each entity of the same type of firework could reference the same instance of the ParticleBehaviour class (since it only contains logic of how the particles should evolve), so there would be no need to create new instances for each entity.

Most basic and direct example:

public class ParticleSystem
{
private final static ParticleBehaviour shootingStarBehaviour = new ShootingStarBehaviour();
private final static ParticleBehaviour bengalFireBehaviour = new BengalFireBehaviour();

...


// when entity dies,
entity.resetAt(float x, float y, float <);
entity.behaviour = bengalFireBehaviour;
...

}

No idea you can make sense of what I mean, but I’ll try to be more detailed if this seems like an approach you could go for.

#8

Hello!
I have subclasses of ParticleEmitter which emit particles in different manners. I would like to avoid recycling entites so I can have different densities of fireworks.
I’m unsure of I can prepare the emitters beforehand using a static context, because when they’re created they go off instantly, and I would like not to miss the strating point of explosions for example :stuck_out_tongue:
I’ll just change to just having one global ParticleSystem - right now I’m having a system per firework, and that is a little unstable…

#9

http://libgdx.googlecode.com/svn/jws/particle-editor.jnlp

http://code.google.com/p/libgdx/source/browse/trunk/gdx/src/com/badlogic/gdx/graphics/g2d/ParticleEmitter.java

#10

I’d suggest you try it the simplest way first, and only bother making it faster if it’s a problem. Ten entities spawning/dying every second or so really isn’t very much… and I doubt that a particle system needs to do particularly heavy lifting on initialization.

#11

You can just have some kind of global object that holds unused particle emitters (basically a cache) and then you can request emitters from there and initialize them.

Like this:


ParticleEmitter ParticleManager.getEmitter()
{
    if (particleList.isEmpty())
    {
        ParticleEmitter e = new ParticleEmitter();
        particleQueue.enqueue(e);
    }

    return particleList.dequeue();
}

void ParticleManager.returnEmitter(ParticleEmitter e)
{
    particleStack.enqueue(e);
}

public Entity()
{
    myParticleEmitter = ParticleManager.getEmitter();
}

public void cleanupEntity()
{
    ParticleManager.returnEmitter(myParticleEmitter);
}

Not necessarily in that exact way, but you get the idea, right? The key is that you’re only keeping around as many emitters as you need at maximum, and you’re never deallocating any.

#12

Hmm… I think it might be better to initialize the pool beforehand, if you’re going to go this route.

The assumption here is that creating a new particle system is a heavy-weight operation, and creating a new one on the fly could be bad (i.e., could cause a frame skip, let’s say).

If that’s the case, though, the above still has the potential to cause it, just less frequently. In fact, you’re going to get new particle system allocations at the worst possible time - when you are already hitting a new high for the number of concurrent entities.

#13

I disagree. The above is a common approach for this sort of memory management. It’s not designed to avoid instantiation slowdowns, it’s to avoid gc slowdowns. Instantiating a particle is not going to be a cost-heavy operation - it’s just creating a bunch of floats or whatever. What’s expensive is constantly removing stuff from memory and then adding it back in. You avoid this issue by never removing anything from memory, which is where the real slowdowns can result.

#14

If you’re using a recent version of the JVM, GC slowdown isn’t much to be worried about, though. 1.4, sure, you might have problems (even allocation is expensive there), but in 5-6, there have been drastic improvements in that area.

It gets expensive when you’re using close to the size of the heap, and it can’t free up enough. Then it starts to thrash, but that’s usually just a precursor to getting out of memory errors. Normally, you’re talking about a couple of milliseconds every few seconds, though.