Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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 systems, pooling and classes  (Read 1233 times)
0 Members and 1 Guest are viewing this topic.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Posted 2004-06-09 19:11:19 »

Righty, everyone must have tinkered with this at some point, so I'm interested in different ways people have done particle effects in their games.

The very basic structure I was thinking of was a Particle class for each one, a ParticleSystem for a single effect (basically an emmiter + a collection of particles) and a global ParticleManager to organise all the systems. Structure shamlessly ripped from a Gamasutra article from ages ago. Grin

1. Object pooling. Obviously we can't go creating new particle objects contantly, or the GC would kill our performance and our first born. An initial idea would be to hold a single big pool in the manager, and dish them out to systems as they requested them. But since each effect is likely to just use a static amount of particles anyway, why not just just let each system allocate its own particles and pool the systems? Anyone any suggestions which may be a better idea?

2. Parallel arrays vs. Objects. The OO way is obviously with a Particle object for each on screen particle, yet with high numbers allocated this may be GC and pool unfriendly. How about parallel arrays in each system for the required properties? This would imply system pooling rather than particle pooling. The downside being that we can't just create a new Particle subclass for new behaviour, and probably a whole load of duplicate code if we have multiple particle system classes.

3. Emmiters vs. complex systems. Should a particle system control emmision rate & properties (implying multiple ParticleSystem classes) or perhaps a single ParticleSystem class and allow different emmiters to be plugged into it?

4. Single generic Particle class vs. Particle interface + several implementations. Things like dust, fire, smoke all need different behaviour, which is easiest to add with different particle classes. Or a generic particle class (essencially a no-code struct) with different controller classes to alter movement behaviour. Problems: becomes awkward when new controller behaviour needs extra data stored in particle object. Or with the other method, multiple particle subclasses makes pooling more tricky.

Ideas?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2004-06-09 20:54:35 »

Oh just code it and stop blithering yer fool.

AF used pools, Super Elvis just uses new and lets the GC take care of it. It GCs here and there but not so you'd notice. AF almost never glitches once it's loaded but really it wasn't worth the effort for a 2-week game like Super Elvis.

AF uses all sorts of clever interfaces and emitters and particle classes for doing points, shadowed particles, and sprite particles, and smoke emitting dots, etc. Super Elvis has one Emitter class and one Particle class with a lot of parameters.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2004-06-09 21:49:36 »

Quote

2. Parallel arrays vs. Objects. The OO way is obviously with a Particle object for each on screen particle, yet with high numbers allocated this may be GC and pool unfriendly.


Um, I don't think so... unless you intend to treat each particle as a uniquely identifiable object that you operate on as individuals? (which IIRC would be unusual for a particle system?). Otherwise, that is not the "OO way", but is symptomatic of a misunderstanding  many people have about what OO is all about (IMHO because it's tricky to understand, got taught originally by bad teachers, and then large numbers of people who didn't understand but thought they did tried to explain it in simple terms, and now everyone's confused Wink. Took me - literally - years to meet a good teacher who also fully understood it and could explain it to me properly).

The OO way would be to identify the thing which has:
- data
- methods which only operate on that data.

(which would suggest to me you only want to work with groups of particles, rather than individuals)

To my mind, this is reinforced by the fact that you tend to emasculate OO if you ever knowingly attempt to assign objects in a way that will be hard to maintain (e.g. if it crosses boundaries that you just know you'll need to split apart, or does NOT cross boundaries that you know you'll NEVER need to split apart).

AFAICS this implies that each "set" of particles should be an object;  if you intend all articles from an emitter to have one behaviour (which is sensible) then you would define your set as "everything from a particular emitter". However, it would make sense to slightly decouple this and add the rider "...created in a particular timeframe" so that you could do runtime alteration of the emitter, perhaps change it's sparks from blue to red - i.e. you would have all it's emitted particles in one set, and then call a method "nextSet()" or simliar on the emitter that would cause it to switch to using a fresh set (i.e. because you want to treat the new particles differently without affecting the old).

FYI this is related to mobs in survivor - we do everything at the mob level, and monsters are just raw basic data, to the extent that many things you might expect us to store on a monster (like the particular skin, or 3D model) we don't - you have to query their containing mob object instead. Although they do have full objects backing them this is mostly because Xith needs a 3D object for each to put in its scenegraph, and partly because java has no structs - so it's a PITA to store small numbers of monsters (only a hundred or so, max) in custom struct-like data structures, instead of just being lazy and using objects Smiley

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #3 - Posted 2004-06-10 11:04:58 »

I agree with Cas, if objects are small enough (just the case of particle entities) CG and contextual creations is not so bad.

We are using this direct technique on MK1 and without any apparent glitch even on low end PC (like 800Mhz or less).

Matteo Anelli
.brain - http://www.dot-brain.com
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2004-06-10 12:32:16 »

Imagine that more or less the only things being created by your game are particles, emitters, and the odd alien. Think how much RAM a particle takes up - maybe 128 bytes. Then think how big the available heap space is in the VM and work out how many particles can get created before you run out and a GC needs to come along. It's a *lot*! And then remember you could turn on concurrent incremental collection and they'd get cleared up continually whilst you're waiting for vertical refreshes.

Cas Smiley

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.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (90 views)
2014-09-10 06:39:09

Tekkerue (44 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (48 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (37 views)
2014-09-07 01:10:19
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!