ENIGMA Forums
General fluff => General ENIGMA => Topic started by: polygone on March 21, 2013, 05:50:40 pm
-
In response to a suggestion that Josh has been throwing around for a while I would like to start a topic about this so it can be further discussed. I for one would like to see it happen.
These are some previous quotes from the Christmas plan topic about it:
Also, who among you is interested in the idea of encapsulating EDL types and functions in their own namespace? It would make it easier to deal with noise from library implementations, but it would require putting lots of shit into that namespace and using lots of shit from STDC.
In other words, we'd no longer have problems with time or list being illegal variable names unless the user specifically said, [snip=EDL]using std::list;[/snip] or [snip=EDL]using namespace std;[/snip], which I intend to unify between all viable backends (meaning, in JavaScript as well).
The new parser is much, much more adept at making these distinctions, so I can probably get it to allow using types and shit as variable names (especially in compatibility mode), but this would be a fix-all.
Encapsulation of EDL types and functions would be nice, especially if it solves the problems with "time" and "list" being used as variable names. How easy would it be to set up the system such that EDL types and functions can reside in both the global namespace and the EDL namespace? If it is easy, I would like the system to be set up that way, since that should enable easy step-wise migration.
Simple as placing "using namespace <name here>;" in the global scope. Just like you would any other namespace. I'll set ENIGMA up to read from :: or ::edlwhatever based on a macro. After everything's migrated, or we think everything's migrated, you'll just flip that flag and try compiling.
-
You don't need to wait for me or the new parser to do this. Just start moving shit into [snip]namespace enigma_user[/snip], or whatever, and then use that namespace from the global scope.
It's actually not difficult to make JDI only read a certain namespace, but I'd rather it wait until the new compiler is out just because we'll have to do it twice, and I don't feel like dealing with merge conflicts when I pour master back into enigma-jdi.
-
Good point about not waiting. In regards to the namespace name, I think Josh's suggestion of "enigma_user" sounds good.
-
Sounds fine it me, I might have gone for enigma_local but it doesn't really matter what it's called :F
-
Is this then on your todo list forthevin? Just so I know.
-
Yes, it is on my todo list.
-
I just realized this is going to be a bitch to do with all the continuous commits, I think it needs to be planned properly.
-
When a proper implementation is layed out and more explicit instructions given I will begin to tackle this. (Y)
-
It would be a good time to do it since there are few commits right now.
-
I have moved some of the user functions and variables into the enigma_user namespace. I will move more later, but I will stay outside of collisions and graphics, to avoid moving things others are moving.
-
I have moved some of the user functions and variables into the enigma_user namespace. I will move more later, but I will stay outside of collisions and graphics, to avoid moving things others are moving.
It's alright nobody is working on any collision or graphics functions right now, I don't think. Now's the best time to move everything, and all at once.
-
Ok I see you've just committed. The problem is those functions aren't going to be available now to people using ENIGMA. This is why it's best to do the whole wrong at once, or at least quickly. Maybe it would be a better idea to branch off actually.
-
No, they are actually available, I tested it myself. The solution is that I put:
namespace enigma_user {};
using namespace enigma_user;
in SHELLmain.cpp, such that the namespace is available to the users, like Josh instructed. That way, user variables/functions that reside in either the global or enigma_user namespace are available to the user.
-
The only thing you should watch out for is some of the existing hacks. Most of them are local to the math header. I define the bessel functions to be declared with a bessel_ prefix to avoid conflicts with variable names like y1. There are other, similar hacks. Removing those will break some games. When the move is finished, the macros that do that will need to be removed, and the bessel functions simply declared in namespace enigma_user to call the corresponding stdc functions in ::.
Make sure, also, that somewhere in the code, [snip=cpp]namespace enigma_user { using ::var; using ::variant; }[/snip] appears.
When you guys are ready, tell me, and I'll make the very few changes necessary to change from :: to ::enigma_user.
-
No, they are actually available, I tested it myself. The solution is that I put:
namespace enigma_user {};
using namespace enigma_user;
in SHELLmain.cpp, such that the namespace is available to the users, like Josh instructed. That way, user variables/functions that reside in either the global or enigma_user namespace are available to the user.
Shouldn't you commit that then?
-
Great to have you back forthevin!!! :smileycat:
-
Josh: Thanks for the heads-up, I will look into that later.
polygone: But that is what I did :). Though I guess I forgot to include that in the commit message.
Robert: Thank you, I am looking forward to spending more time on ENIGMA, it has been too long :).
-
Ohhhh I see, you can use them but LGM is not picking them up for the function list.
-
Does this resolve the issue with Box2D functions not being highlighted? That also needs worked out.
-
No. Those aren't updated because Ism only checks for function names once.
-
Forthevin can you tell me exactly how I am supposed to do this? I am good at helping with these very monotonous things like moving functions to a namespace, but Josh told me to hold off because it is very easy to mess up, and now I don't know how to start doing it. As far as I think I just need to move the function declaration and definition in the headers and sources into namespace enigma_user { } is that correct?
-
Robert, I think you are right that it primarily is moving function (and variable) declarations and definitions in the headers and sources into namespace enigma_user. All the functions that are directly available to the user should be moved to enigma_user. There are a couple of things to watch out for:
First off, when moving a user function, there may be other parts of the code that call that function. The fix is simply to prepend the call to the function with "enigma_user::", since the namespace for the function has changed and thus needs to be qualified properly. For code that already is in enigma_user, this should not be necessary, since calling functions in the same namespace does not require qualification.
Second off, be careful not to move any [snip]#include[/snip]s into the namespace, since anything "included" will then be put into the namespace. Most of the time, this should just mean looking through the function declarations and definitions and moving all "includes" to the top.
There may also be issues with the hacks Josh mentioned before. There are a lot of user functions in the graphics systems, and I have just looked through it and haven't found any dragons, so I think that if you focus on moving user functions to enigma_user in the graphics systems and follow my guidelines, you shouldn't encounter any issues. If you do, let me know, and I will take a look at it.
As a side note, it should be possible to move the user functions little by little, so compiling and running frequently to verify that things work is a good idea.
-
Just a heads-up to avoid duplicate work; I will begin moving the collision system user constants, variables and functions to namespace enigma_user soon.
-
Hey sorry forthevin I didn't respond to that, I have gotten sidetracked with LGM and NGM, and I am waiting for Ism to come and build the new LGM jar. I am currently writing a 3D/2D scene editor for our new IDE...
(http://oi41.tinypic.com/30kx3s8.jpg)
I won't be working on the engine for quite some time yet, however I did move Box2D to an extension so it can be used in conjunction with bounding box collision systems and for instance could allow you to use it with Newton or Bullet at the same time, think GTAIV and how it has 2D minigames. YYG messed up their system so I proivde one that is compatible with theirs but I am also writing my own. Also be aware to check the particles extension I broke it when I created the general header includes for graphics systems Josh told me too, we need to create a bridge there because particles need to use the current graphics system, not OpenGL1 only.
-
Hey Robert, no problem, I have been busy with moving parts in other systems first, so I have only just now gotten around to it. I saw that you split it in two; providing a compatibility option for users is a good idea.
In regards to the particle systems, I am going to fix it after the namespace move is done and tested. I have some ideas for ensuring that the particle systems and the graphics system are not mutually dependent like I originally wrote it, but only that the particle system is dependent on the graphics system. I am thinking about putting the bridges (as in the parts of the particle system which is specific to a given graphics system) themselves in the particle systems, and ensuring that the graphics system is agnostic as to which particle system (if any) is being used. That would also be useful if we add more particle systems later and change the mechanism from an extension to a subsystem. A different way would be to make the graphics code in the particle systems independent of the graphics system, but I believe that better performance can be achieved if the particle systems can use code specific to each graphics system, so I am going to go in that direction.
And as a second heads-up, I have just moved the collision system, and I am going to begin moving the graphics system soon :).
That screenshot looks nice; will the user be able to put objects and move them around in 3D, and will the user assign each object a model instead of a sprite?
-
Yes that was also why I asked everyone for a hardware diagnosis a while back to compare and contrast with the Steam survey.
Wonderful anyway, like we've also discussed we need to work out graphics systems being independent of Window. Take for instance I also want to an OGRE graphics system and OGRE provides its own Windowing for each platform so it will be Windowing system independent, however for DX I need a bridge that exposes the hWnd window handle from the Win32 windowing system to the DX graphics system. It needs hWnd to create the d3d rendering device and target, as I cannot put that into the Win32 windowing system because it is also used by the OGL graphics system.
I am also planning to abstract your particle system to be able to do 3D particle effects as well. I will also be creating a particle effects designer for the new IDE NaturalGM so that you won't have to mess with code to create nice looking particle effects and stuff.
As far as the Scene Editor, yes it does do that, but it is also 2D. It memorizes 3 different camera projects, Perspective, Orthographic, and Isometric allowing you to easily flip between them and you can also control other things such as fog and what not and it is also hardware accellerated and uses OpenGL. But this also brings me to another point of reusable code, such as basic shapes and mesh classes, I am trying to think about sharing them between the engine and the IDE.
Edit:
It is going to use the Unity3D style cube for locking axis constraints...
(http://oi44.tinypic.com/67o5jr.jpg)
-
Supporting a particle system with 3D effects would be very useful to certain games. I don't think it would be easy to extend the current system to support 3D effects, but I do think I could refactor it into making it easier to support such an extension. I could well do that while I refactor the system to solve the current issues with it.
A particle effects designer would be very useful; there are particle effects designers for GM currently, but they are not cross-platform.
Being able to flip between different perspectives easily and according to what perspective the current game or room needs sounds very useful. I can also imagine being able to flip between them in a 3D game would be great when designing levels; getting an overview using the orthographic camera, and using the perspective camera when building the different rooms/sections.
In other news, most of the user-level constants, variables and functions have been moved to the enigma_user namespace. All the current extensions have been moved (except for the particle systems, which I will move after I have fixed and refactored them to the new system), the OpenGL 1.0 and 3.0 graphics systems have been moved, everything in Universal_System have been moved, OpenAL and FMOD music systems have been moved, BBox, BBox3d and Precise collision systems have been moved, and both the Linux and Windows code in Platforms have been moved. I haven't moved DirectX 10.0, mostly because it doesn't run yet, but it should be easy to move now that most of the other stuff have been moved, including the OpenGL 1.0 and 3.0 graphics systems. I have also fix a few bugs here and there, and I have refactored mathnc.{cpp,h} as well; Once the switch to enigma_user has been made, a couple of changes will need to be made there (basically just deleting and uncommenting a couple of lines and testing that it works).
Josh, in regards to the switch to enigma_user, I would like to request you to notify me once the switch is ready so I can try out the switching before it is implemented in the master branch. While most things have been moved, there may be some things I have missed, and so I would like to try and run some different games and tests to ensure that they compile and run, and fix any potential issues that occurs after switching, before the switch is committed to the master branch.
My plan for the future is right now to fix any issues that may crop up due to the move to enigma_user, and otherwise work on the particle systems.
-
Si senior fothevin these are my intentions :)
And thats good your planning ahead on working out issues (Y)
-
So ForTheVin what percentage are you exactly through the enigma user move? And when is Josh going to change JDI to deal with it.
-
Hey polygone, sorry about the late response. With the latest commit I think the percentage is about 90% to 95%. In the latest commit, I have gone through all of the files in the Universal_System folder and moved the remaining parts to be moved. One part I didn't moved was instance_id, since that hasn't been fully implemented yet. I added a TODO to it instead, since moving it while fixing it should be easy. There are a couple of subsystems that I haven't moved, due to one reason or another. For instance, I haven't moved the functions in the OpenGL ES graphics system, and I don't think that is an issue; it will need to be fixed later on in any case, and it should be easy to move the functions there then. I suspect that there may be special cases or corner cases that I haven't handled yet, but since the majority of the functions have been moved and tested, and any errors will be encountered as compile-time errors, it should be easy to move them when they are encountered.
-
So basically you are finished now?
-
Yes.