|
forthevin
|
|
Reply #16 Posted on: April 28, 2013, 05:38:05 pm |
|
|
Joined: Jun 2012
Posts: 167
|
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 .
|
|
|
Logged
|
|
|
|
polygone
|
|
Reply #17 Posted on: April 28, 2013, 06:13:50 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Ohhhh I see, you can use them but LGM is not picking them up for the function list.
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
Goombert
|
|
Reply #18 Posted on: April 29, 2013, 02:41:54 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Does this resolve the issue with Box2D functions not being highlighted? That also needs worked out.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Josh @ Dreamland
|
|
Reply #19 Posted on: April 29, 2013, 03:45:40 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
No. Those aren't updated because Ism only checks for function names once.
|
|
|
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
|
|
|
Goombert
|
|
Reply #20 Posted on: April 29, 2013, 04:47:39 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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?
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
forthevin
|
|
Reply #21 Posted on: April 30, 2013, 04:20:18 pm |
|
|
Joined: Jun 2012
Posts: 167
|
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.
|
|
|
Logged
|
|
|
|
|
Goombert
|
|
Reply #23 Posted on: May 15, 2013, 04:45:09 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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... 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.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
forthevin
|
|
Reply #24 Posted on: May 15, 2013, 07:58:34 am |
|
|
Joined: Jun 2012
Posts: 167
|
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?
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #25 Posted on: May 15, 2013, 08:16:09 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
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...
|
|
« Last Edit: May 15, 2013, 09:39:12 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
forthevin
|
|
Reply #26 Posted on: May 16, 2013, 03:16:59 pm |
|
|
Joined: Jun 2012
Posts: 167
|
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.
|
|
|
Logged
|
|
|
|
|
polygone
|
|
Reply #28 Posted on: June 20, 2013, 10:08:54 am |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
So ForTheVin what percentage are you exactly through the enigma user move? And when is Josh going to change JDI to deal with it.
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
forthevin
|
|
Reply #29 Posted on: June 26, 2013, 06:39:25 pm |
|
|
Joined: Jun 2012
Posts: 167
|
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.
|
|
|
Logged
|
|
|
|
|