Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Particle design in Slick  (Read 4281 times)
0 Members and 1 Guest are viewing this topic.
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Posted 2011-02-14 08:05:01 »

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.

Offline ra4king

JGO Kernel


Medals: 345
Projects: 2
Exp: 5 years


I'm the King!


« Reply #1 - Posted 2011-02-14 08:06:44 »

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

Offline Addictman

Senior Member


Medals: 3
Projects: 1


Java games rock!


« Reply #2 - Posted 2011-02-14 08:20:04 »

Hey.

A couple of questions Smiley

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?)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Addictman

Senior Member


Medals: 3
Projects: 1


Java games rock!


« Reply #3 - Posted 2011-02-14 08:22:49 »

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


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

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #4 - Posted 2011-02-14 08:54:11 »

Hey.

A couple of questions Smiley

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?)


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 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.)


Offline TheMatrix154

Junior Member


Medals: 2



« Reply #5 - Posted 2011-02-14 09:18:13 »

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 Smiley

Offline Addictman

Senior Member


Medals: 3
Projects: 1


Java games rock!


« Reply #6 - Posted 2011-02-14 11:51:31 »

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.
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #7 - Posted 2011-02-14 15:09:00 »

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.

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 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..

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #8 - Posted 2011-02-14 21:18:23 »

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

Offline avm1979
« Reply #9 - Posted 2011-02-15 17:19:38 »

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'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.


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #10 - Posted 2011-02-16 05:49:10 »

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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
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.

See my work:
OTC Software
Offline avm1979
« Reply #11 - Posted 2011-02-16 16:24:01 »

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.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #12 - Posted 2011-02-17 21:20:42 »

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.
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.

See my work:
OTC Software
Offline avm1979
« Reply #13 - Posted 2011-02-18 21:09:59 »

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (27 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!