Pages: 1 2 »
  Print  
Author Topic: The particle systems extension is complete  (Read 4318 times)
Offline (Unknown gender) forthevin
Posted on: February 09, 2013, 02:27:53 PM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
I am pleased to announce that the particle systems extension is complete. Turn it on under Enigma->Settings->Extensions->ParticleSystems in order to use it.

All particle and effect functions and actions have been implemented and tested. It includes attractors, destroyers, deflectors and changers.

The performance of the extension is near the level of GameMaker. It is able to update and draw 10.000 particles at 30 fps on my hardware with a quad-core processor and an Intel integrated graphics card. My latest profiling indicated that updating and drawing take about the same amount of time, with drawing taking slightly more, so optimizing either updating or drawing makes sense. As a side-note, the initial profiling and optimization made the drawing about 10x faster, since it turns out glPushAttrib can be pretty expensive inside a loop. Further profiling and optimization improved the performance slightly. The updating is fully single-threaded, though there are some parts of the updating which could be parallelized.

The particle systems extension is generally decoupled from the used graphics system. Most of the extension is fully separate from the graphics system used. The graphics-dependent parts are handled by requiring the used graphics system to implement a function to draw a vector of particle instances. The only coupling remaining in the particle systems extension is a few includes of OpenGL/GScolors.h, which only uses the non-drawing functions of the header.
Logged
Offline (Male) Josh @ Dreamland
Reply #1 Posted on: February 09, 2013, 05:51:04 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2960

View Profile Email
I'm very pleased to hear that, forthevin!

On the subject of the sovereignty of your particle system... How does the idea of a Particle_Systems directory strike you? We'd place it either in the root of SHELL or in the GL folder. Probably the former, since some particle systems may be written which use exclusively draw_* functions, though I'm not sure who would do such a thing.

What I more believe may end up happening in the future is providing a different particle system controller that moves your particle functions to the GPU via GLSL, in the interest of performance. The GPU particle functions would be more limited (a fixed limit of attractors/emitters/etc), so it would still be useful to offer both systems and let users pick the system which better suits their particular game's needs.

Note that I'm not expecting nor even asking you to do any of this personally (especially since the main graphics system still does not utilize any modern GL aspects, least of all shaders), I am merely stating that it is a possibility, and something to consider while we're ahead.

So, thoughts?
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) polygone
Reply #2 Posted on: February 09, 2013, 11:17:09 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
All the extension are nicely placed together. I think maybe the Extensions folder should be moved though from US to the SHELL root?

What are you up to next then forthevin? There won't be many GM functions left soon. Of course there's some stuff to do after Josh finishes his shit, but he's usually on the toilet quite a while so God know when that will go down.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) forthevin
Reply #3 Posted on: February 10, 2013, 08:44:44 AM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
A Particle_Systems directory is a good idea, given that it provides multiple options for users as you say. I originally didn't consider the possibility of using shader languages such as GLSL for implementing particle systems, which is why I decided on having a single particle systems implementation for all graphics systems.

For the design of the system, I think it would make sense if each particle system implementation can be restricted to specific graphics systems, such that a GLSL particle system implementation can only be used together with OpenGL and OpenGL ES graphics systems, and a HLSL particle system implementation can only be used together with a DirectX graphics system.

In regards to the use of attractors, destroyers, deflectors and changers, either restricting or removing them for certain particle systems implementations would make sense, given that YoYoGames have removed them in GameMaker:Studio, presumably because they themselves use a shader-based implementation for Studio.

As for the future, I don't have any plans currently, apart from fixing various issues, improving on things here and there, and implementing some more unimplemented functions.
Logged
Offline (Male) Josh @ Dreamland
Reply #4 Posted on: February 10, 2013, 10:38:19 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2960

View Profile Email
> I think it would make sense if each particle system implementation can be restricted to specific graphics systems
Certainly; existing systems name such dependencies all the time. Some might even depend on physics or collision systems, or audio systems. Who knows.

> that a GLSL particle system implementation can only be used together with OpenGL and OpenGL ES graphics systems, and a HLSL particle system implementation can only be used together with a DirectX graphics system
What may be a better idea is to start devising a shader language specifically for ENIGMA which can be compiled to all of HLSL, GLSL, and whatever GLES's GLSL is called (I know little about GLES). This way, a GPU-side particle system could be used with any graphics system which supports compiling ESL, or EASL, or whatever we would call it.

I don't know why there isn't a unified shader language already. My guess is that either there is, and I don't know of it, or there isn't, because shader languages are already so similar that the real issue is with all the other aspects of the graphics API.

Of course, I probably shouldn't be scheming right now given that I barely have the time to write up this post. It's just a consideration (And it happens to be a consideration I've had for some time, though not with regard to particle systems).


Anyway, as far as what you should do next, it's up to you. I'm not very concerned with missing GM functions, at this point, as the missing ones largely depend on features of ENIGMA that just aren't there yet. My goals are a bit lofty, but if you like, I can put them up on the wiki over the course of the next couple days.
« Last Edit: February 10, 2013, 10:40:16 AM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) forthevin
Reply #5 Posted on: February 10, 2013, 01:55:41 PM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
Regarding GLES's GLSL, I have looked a bit into it. It is based on version 1.20 of GL's GLSL, and while similar, it is different enough to be its own language from GL's GLSL.

I also looked into unified shader languages. There does exist a unified shader language, Cg, which is developed and supported by Nvidia. Nvidia provides tools to convert from Cg to GLSL and HLSL. Notable users of Cg include the Unity engine and Irrlicht. Unity supports GLSL and Cg, while Irrlicht supports both GLSL, HLSL and Cg. I think the choice of shading language should be postponed until someone wants to use shaders. That said, Cg seems like a good candidate.

I would definitely like having your goals on the wiki.

As a side-question, have a Work in Progress forum been considered at any point? ENIGMA is not yet complete in terms of features, but it has been mature enough to make games in for some time.
Logged
Offline (Male) polygone
Reply #6 Posted on: February 10, 2013, 02:29:29 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
Josh has added his goals to the wiki. And I have also scoured the ENIGMA source for odds and ends that need to be done and added those to the wiki also.
http://enigma-dev.org/docs/Wiki/ENIGMA:Todo

Preferably this wiki list should be maintained by individuals when they complete a task or add todo points in the ENIGMA source.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) forthevin
Reply #7 Posted on: February 11, 2013, 03:01:51 AM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
Very cool.
Logged
Offline (Male) polygone
Reply #8 Posted on: May 30, 2013, 10:33:25 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
Should the particles extension not be on by default?
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) forthevin
Reply #9 Posted on: May 30, 2013, 11:37:09 AM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
I originally preferred that the particles extension was not on by default, since most games do not use it. That said, particle systems are a core part of GM, so I think it could make sense to make it on by default.
Logged
Offline (Male) polygone
Reply #10 Posted on: May 30, 2013, 12:00:33 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
Actually I don't think they should be an extension at all. They seem like a typical set of OpenGL functions.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) forthevin
Reply #11 Posted on: May 30, 2013, 12:36:23 PM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
Most of the particles extension is independent of the graphics system used. While I think it could make sense to put it in the general part of the graphics systems folder, I believe we should not do this for two reasons: First, it would be nice to be able to turn off the particles if you don't use them. Many games do not use particle systems. Second, it may be nice to create a different particle systems implementation in the future. Robert have suggested that we should add 3D capabilities to the current system, and Unity seems to do particles in a good way, which it would be nice to support in the future. The best way to support these systems would in my opinion be to change particle systems to a main system instead of an extension. At the moment, I think it is fine that we postpone such an upgrade, and let the current system stay an extension, until we begin work on another particle systems implementation.
Logged
Offline (Male) polygone
Reply #12 Posted on: May 30, 2013, 12:42:51 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
The fact that they are GL dependent means they should be contained in the graphics folder though. They fit with the other graphics files, plenty of them are very large as well. In the case where other particle systems are to be written then they should be in the API selection not extensions. Doing this you can then add a <none> option.
« Last Edit: May 30, 2013, 12:59:24 PM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) forthevin
Reply #13 Posted on: May 30, 2013, 01:55:46 PM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
The only GL dependent parts are the graphics systems bridges, which sum to about 600 lines of code. A lot of the code is not related to graphics, only to handling the particles themselves. The number of lines of code in the particles extension is about 6500. Each of OpenGL{1,3} is in the range of 8000-9000 lines of code. Given their size, and that there is a lot of the code that does not deal with graphics, I think it makes sense to isolate them as an extension. The bridges to OpenGL1 and OpenGL3 are relatively small, about 200 and 400 lines of code, respectively.

I agree with the part about them being in the API selection if other particle systems are to be written.
Logged
Offline (Male) polygone
Reply #14 Posted on: May 30, 2013, 02:17:26 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
But I'm not sure I'm actually seeing any benefit to having the particles in an extension. I thought extensions were just so people could disable systems that use instance local variables and thus save memory, or for disabling a system that might get in the way. I'm not sure how particles fit into that.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Pages: 1 2 »
  Print