Closed craftworkgames closed 8 years ago
I'm going to start some work on this, here are my very rough plans:
Classes:
Particles and emitters have a position, particles have velocity, angular velocity, time until death, texture, size, etc.
Particle engine manages killing particles, updating emitters, etc.
Emitters manage creation of particles with parameters including spawn frequency, ranges for size, etc.
For the record, the reason I am designing a custom solution is because all of the particle engines that I have been able to find that seem to work well are optimized at the DirectX-level or something similar, and are for that reason platform-specific. I think I should be able to come up with a reasonably high performance solution, even if it can't maintain quite as many particles as an optimized engine such as Mercury.
Particle systems are a rather big job. I don't mind if you start working on it but keep it in a different branch for a while until we get the design concrete.
@Matthew-Davey how do you feel about us borrowing some of the design from your excellent particle engine? I couldn't find the license.
Particle (struct?)
Yep, structs are probably the way to go for performance reasons. Although, they do have some downsides (can't implement interfaces).
ParticleEngine (static?)
Try to avoid making static classes as much as possible. There are a few uses for static classes; this is not one of them. In particular static classes that that hold global state are very bad design.
We are going to end up with more and more of these types of classes that have Update
methods on them. I've been thinking about this a lot lately and there's a few issues I'll discuss later, but the first is naming.
I'd like all these types of classes to be consistent. Currently we have InputListenerManager which kind of irks me a little. So potential names could be:
ParticleManager
ParticleSystem
ParticleEngine
For now, don't worry about the naming too much. I'll raise another issue about cleaning that up shortly.
Alright, sounds good. I'll probably have a working demo tomorrow or this weekend sometime with a simple-ish set of code, then I'll try sticking it into Monogame.Extended in a branch so we can do some discussion.
I'll try sticking it into Monogame.Extended in a branch so we can do some discussion.
Let me know if I need to create a the branch on my end or whatever. I haven't done a lot of branching before but I want to get into the habit of branching more often.
Let me know if I need to create a the branch on my end
You don't have to for now, but I may ask you to in the future. While only I am still working on it, there's no need to have a branch in the main fork (aka your copy of this repo here on Github), however I won't be able to push my fork over here unless you make a branch that is equal to master, then I can open a pull request specifically for that branch, updating the branch on this fork to the branch on my fork.
I have a very simple codebase right now, but it seems to work. It's a bit hacky and needs a lot of work, but it's functional. Here's a video!
Looks great. It's always fun to write particle systems :fireworks:
Hey guys sorry for the slow response. If you did end up borrowing any code from Mercury then have no fear, it's covered by the http://www.wtfpl.net/ :sunglasses:
Cool. Thanks @Matthew-Davey
I recently made some changes to mpe so it can be used with monogame (it just needed a renderer that used a spritebatch really). I was planning on setting up a gist or a repo for it. I made some additions other than the renderer too and refactored some stuff (mostly to dig in the code and get a hang of te structure). I'm working on a winform editor for the effects now, and want to let it use the IntermediateSerializer in MonoGame for easily loading the effects into your game. Kudos to Matthew for the engine, i really like it!
@Jjagg That sounds cool. Do you have any links to what you've done?
What's the plan here? Do you want to integrate it into MonoGame.Extended somehow?
It's pretty large, so I don't think it should be added here. I noticed that's been said before here, so maybe it would be nice to link other useful tools for MonoGame in the readme. That way this repo could be a sort of central point where MonoGame developers can find all kinds of useful tools. As I said, the particle engine stuff is a work in progress, so no repo yet. I made some large changes too, so the SpriteBatchRenderer as I have it won't work with the original library, but it would be easy to whip up something that will.
That way this repo could be a sort of central point where MonoGame developers can find all kinds of useful tools.
That's a good idea. I'll have a think about how this might work.
As I said, the particle engine stuff is a work in progress, so no repo yet. I made some large changes too, so the SpriteBatchRenderer as I have it won't work with the original library, but it would be easy to whip up something that will.
I'm really interested to see it. Keep me informed if you put it in a repo :)
It's up there! https://github.com/Jjagg/MgMercury I put up a little gist in case you'd like to test it. https://gist.github.com/Jjagg/716924e108a84f0ace19
Edit: I removed everything related to the editor as it made the code less nice (I use a propertygrid in the editor, so I had to make all fields into settable properties and added a lot of attributes). Maybe later I'll put up the editor too, but I'm currently not actively working on it anymore. EditEdit: I struggled a little with git, so if you run into any problems let me know!
@Jjagg I really like what you've done here but I've only just come back from holidays and I haven't had time to try it out yet. Hopefully I'll get to it soon.
@Jjagg I finally got around to trying this (sorry I forgot about it).
I modified the parameters a little to make it more interesting. Here's a screenshot. You're welcome to use it on your project page if you like :smile:
Anyway, are you interested in integrating this into MonoGame.Extended somehow? I think perhaps it's the first case for a new DLL / NuGet package to isolate the dependency. Something like MonoGame.Extended.MercuryParticles.dll perhaps.
Cool, no problem! It's a good idea to put it up separately. How do we go about that? I'm not very experienced with any of this :) It's actually fine too if you want to build it and do something with te dll. I just started working on the project I'm using this for again, so I'll probably update here and there and I definitely plan on making a decent editor.
It's actually fine too if you want to build it and do something with te dll.
Awesome. I'm currently working on a GUI system which will take a while but once I'm finished that I'll start thinking about particles.
Looking good guys. FYI you don't have to use the Mercury name, you can just absorb the code into your own MonoGame "brand" - just a small mention of Mercury somewhere in the readme smallprint would be appreciated :)
you can just absorb the code into your own MonoGame "brand"
Thanks again Matt. That's a much nicer solution.
I've started the process of absorbing Mercury into MonoGame.Extended. The code is in the particle-system
branch if anyone wants to have a play with it.
Thanks again Matt.
Could you put those three animations you've created in as Demos? There are no good demos for the particles extension. It could really use some love.
A particle system like the Mercury Particle Engine seems like a good addition for completeness.