Particle for entities

[Gornova]

Particle emitter entities. Some simple entities to add Slick's particle stuff into the game ;-)

[thaaks]

Just saw your implementation in your dev branch. Good that you started with it.

But I think your current implementation has some design flaws:

1. Only one ParticleSystem stored in ME. The problem will be that if you switch Worlds, from game to title for example, all particle emitters from game will still appear in title world because they share the same single ParticleSystem and update and render it, because that is hard coded in World update() and render(). So my suggestion is to have at least one particle system per world!
2. Particle system should be aware of scrollable worlds. So another vote for one particle system per world. And we need to test how that works with scrolling levels. I might have to look up my SpiderTrap source code. There I already solved it somewhere in my Map class.
3. I still prefer my idea to wrap a Particle System inside an Entity. This way we can render several particle systems at separate depth layers!!! Which might not always be required but nice to have anyway.

What's your opinion here?

[Gornova]

hi and well.. my opinion :D

1. I agree, one for world
2. yes, test is need, but again on particle sytem for wold
3. i don't want to add more complexity on Entity because particle system seems to me something related not on a single entity, but something created into world and controlled using world. So no entity: for layers we can always render particles using layer order.. but I'm understand your problem.

I'm not sure what is best option now, storing particle system on ME is not right point, I agree, but in entity.. seems strange.

A question this time: player touch bonus, so I add my emitter to particle system, but how to have more control on it? For example some tweens on alpha or som alarms ? We need to think about that to have different kind of effects

[thaaks]

1 and 2 and 3: you're right. Let's keep it simple. One particle system per world, rendered above entities and below the above list of the world (HUD and stuff like that).

Your question: so you're thinking about a wrapper around a particle emitter, right? So maybe wrap an Emitter into an Entity? :-) No, just kidding. Maybe we create some simple wrapper class Emitter that allows us to have alarms and tweens and such. This would mean to have a common super class for Entity and Emitter with the above functionality for example. Shouldn't be too complicated. BTW: Because you already started working on particles: I think we can also move my empty particle test case into the proper new it.marteengine test package.

I think I'll merge your dev branch into my devtommy branch tonight ;-)

[Gornova]

we talk when you have merged my branch, because change of package will be a pain :D

[thaaks]

Baah, you're so mean :-p

[thaaks]

Haha, that was easy :-) Had to merge just one test case that couldn't be merged automatically. The rest "just worked(TM)"!

I'm with you now ;-)

Let's keep on moving with particles! The more I think about it: What you want to do with "smart emitters" is: deal with alarms, use tweens, maybe add some collision rectangle to check for collisions with a "smart emitter". This all sounds like some EmitterEntity to me. But that's not possible because an EmitterEntity can't inherit from Slick's ParticleEmitter AND from Entity. But an EmitterEntity could wrap a ParticleEmitter. Whenever you add a ParticleEmitter to the world it could add it's wrapped Emitter to the world's ParticleSystem. Furthermore it could delegate all desired stufff (changing position, alpha, etc.) to the wrapped Emitter. And you would get alarms, tweens and collisions too. That should work. The constructors could receive coordinates and XML file or coordinate and other Emitter/EmitterEntity to duplicate from. I think that would be worth a try. What do you think?

[Gornova]

I agree, it worth it!

[thaaks]

I added some simple EmitterEntity (renamed the existing ParticleEntity), moved the ParticleSystem from ME to World and finally added some testcase ParticlesTest to proof it's working. Please have a look at my testcase and code changes in my devtommy branch and give some feedback. The current implementation is pretty simple but sufficient.

[thaaks]

The current approach (one ParticleSystem per World) only works if you limit yourself to single emitters which can then be added to the ParticleSystem. But what if you use Pedigree to create some complicated effect that relies on several emitters working together? In this case Pedigree generates a separate ParticleSystem which references all included emitters. Our approach couldn't deal with that. So I am thinking about adding an ParticleSystemEntity which does indeed wrap a complete Slick particle system with all its emitters. This way we have both worlds: simple emitters that all use the ParticleSystem of the world and complex ParticleSystemEntities which have more flexibility. Your feedback is highly appreciated ;-)

[Gornova]

Thanks to your comment on Fuzzy (about adding some particle!) I'm dealing this kind of problem right now, so I agree, if we think developer can use Pedigree to design particle, all help we can have on this side is appreciated, so go for this kind of deep integration: one entity load all information about particle system designed with Pedigree and then diplay it, simple and useful :D

[thaaks]

Have a look at my devtommy branch. Single emitters can already be wrapped by EmitterEntities. That's working and a testcase is included!

I'll have a go at some ParticleSystemEntity class the next few days. I think it'll be pretty simple.

The EmitterEntity might need some additional constructors to deal with all those different Emitter classes of Slick. If you miss something or know something feel free to post it here ;-)

[thaaks]

Just added a constructor for ParticleEmitters (the Slick interface) and for ParticleSystems (but not yet committed - still WIP). I'm currently trying to decide if it's better to keep one class (named ParticlesEntity) or create separate classes (ParticleSystemEntity, ParticleEmitterEntity). If all is in one class we have some conditions that need to be checked and treated differently. For example if it's an entity with a ParticleEmitter it must be added to the world's particle system to become visible. If it has it's own particle system it uses that one. Positioning affects the particle system or the position of a ConfigurableEmitter but is not possible for "normal" ParticleEmitters cause setPosition is not part of the interface. You can only create them at some fix position.

Do you have any input or opinion here?

[Gornova]

none for now :D but I'll check your implementation as soon is possible :D

[thaaks]

I just committed the current WIP stuff to my devtommy branch. You should be able to have a look now.

[Gornova]

thanks!

can you merge my changes to dev into your branch so is more simple to merge this stuff back ?

[thaaks]

I'm pretty much off to vacation so I could do it only after my vacation in around two weeks...

[Gornova]

no problem !

[thaaks]

Just started last night merging your dev branch into my devtommy branch. Not finished yet. Testcases (including Fuzzy) are still remaining. Will have to give it a good test run after all this merging ;-) I'll keep you posted when I'm done.

[Gornova]

ok let me know!

[thaaks]

Hiho, I merged your dev branch into my devtommy. Not sure how much I messed it up ;-) But Fuzzy and StarCleaner worked fine.

Do you want to have a look now?

I'm not sure about your ME.renderParticle instance var. I moved it to World because, as I told you before, each World has it's own particle system now. But IMHO it doesn't make much sense. If you don't want to render particles you might better remove the particle system. But anyway, it's in World and works the same way as it did in ME.

Have fun, Tommy

[Gornova]

Yeah! good work! I'll take a look into your branch soon, we are ready to ship version 0.3 soon :D