Next topic

[forthevin]

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?

[polygone]

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

[forthevin]

The particles extension is on by default now.

[polygone]

ok lol. That wound up being a long discussion just to result in toggling a boolean

[Goombert]

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.

[forthevin]

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.

[Goombert]

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. 

[forthevin]

Sounds good. I will be careful when doing any movements or changes in the engine.

[Goombert]

Hey its ok forthevin I just don't want to have to go though creating another shell again  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)/