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.
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?
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.
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.
> 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.
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.
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.
Very cool.
Should the particles extension not be on by default?
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.
Actually I don't think they should be an extension at all. They seem like a typical set of OpenGL functions.
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.
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.
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.
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.
I think that is the main reason for it, but there are also other systems there that do not have local variables (such as the DateTime extension), so I also think it can make sense to turn isolated systems into extensions, even when they do not have local variables. The advantage seems to be that there is less to compile and include in the resulting game binary. I also think it will be easier to turn it into an API selection with it being an extension.
That said, I don't think there is much difference to having it in the graphics system. I am mostly against it because it is more work for little or no gain as far as I can see, and the current system works :).
In regards to the original question, I think it could make sense to turn the particles extension on by default. Should we do that?
Quote from: forthevin on May 30, 2013, 07:51:25 PM
In regards to the original question, I think it could make sense to turn the particles extension on by default. Should we do that?
Yes turn it on as default anyway. I'm not actually too fussed where it is really, you're right that it works now maybe don't want to screw with it and there's more pressing things to do than move that around.
I think I remember Josh saying though that extensions don't affect the resulting game binary. You're probably right about the loading time though, but I'm thinking it's not gonna be a huge speed gain :p
The particles extension is on by default now.
ok lol. That wound up being a long discussion just to result in toggling a boolean :P
Polygonz, if there is ever only going to be two versions of our defactor particle systems, then it does not need to be a system and it is not going directly into the graphics system. It is fine as an extension, however forthevin, what part of the OpenGL API does it rely on? Because I have taken the position of just using the engine functions to reduce reliance on any given API, thus making the particle systems work for both the planne DirectX system as well as current graphics systems.
The bridges are the only parts that rely on OpenGL specifically. The OpenGL1 bridge relies on the fixed pipeline and direct rendering, while the OpenGL3 bridge relies on shaders (GLSL 1.3, corresponding to OpenGL 3.0), VBOs and vertex arrays.
In regards to reducing reliance on any given API, I think you have a good point. I still think it is good to be able to specialize the particles drawing for each graphics system, since there ought to be a potential gain in performance by doing so. I think I have a solution for the issue: Use the engine functions in a fall-back "bridge", which is used when there isn't a bridge available for the currently used graphics system. That way, we get the potentially increased performance when available, and we still don't rely on any specific graphics system.
Speaking of bridges forthevin, I am working on the graphics system bridges for windowing right now and will have it ready to merge in soon, me and polygonz are going to begin working on the DirectX graphics system. I just wanted to let you know, be careful when move the functions to enigma_user when reliance on them exists in Universal_Systems or anywhere other than Graphics_Systems as this then requires the DX system to also have them in the same format, I had to reshell the whole DX system before I could even start, and I can't keep starting from scratch over and over. All you gotta do is ask me to make the changes and I can do so, or if you can test on Windows then of course you can just do it yourself. :)
Sounds good. I will be careful when doing any movements or changes in the engine.
Hey its ok forthevin I just don't want to have to go though creating another shell again :D its monotonous. Anywho I have successfully bridged Win32 and seperated the OpenGL from DirectX stuff, I am not worrying about bridging the stuff out of X11 untill I do the OGRE port. Now I have my pull request ready there and I have tested it on both Desktop and Faptop Ubuntu 13.04 PC's and my Windows VM and all systems appear good to go. My next part is trying to create the damn swap chain and d3d device but I am having no such luck :( honestly it is like Microsoft doesn't want us to use their shit software? You can't even get the include or lib paths correct in the damn makefile because they have to put *(&*((*$&%$% symbols and spaces all through the install paths, eg. C:/Program Files(x86)/Microsfot DirectX SDK (June 2011)/