Sorry to hear about that but I understand all too well the lack of time.
Best of luck for now and I'm looking forward to seeing progress on Ocean when you're back on it.
Just dropping a line to say I'm alive and still waiting to have time to work on Ocean.
Meanwhile, the company I work for, has intentions to start mobile dev project and I'm evaluating few possibilities.
It's possible that in the near future I'll use ORX for the project the have in mind but I need to better understand a thing.
I would integrate libRocket with ORX for Windows, iPhone and Android (well...mac and linux too).
That would be useful for Ocean, for my game, and for the company projects.
It all depends on what you mean by integrating libRocket with orx.
If you simply want to run libRocket on top of orx and hook it to its display, that shouldn't be too much work. If you want to integrate it at a lower level (and add a GUI plugin/module), that's going to be much more work. The actual new module/new plugin implementation part is easy, but the part where we need to define a generic way to describe UI items with orx's syntax and bridge them to libRocket is going to require a huge amount of work I think. Unless you restrict that generic interface to a strict minimum.
Just a quick note to let you know that I fixed some issues with orx with respect to minimization/iconfication, especially on windows. Not sure if it affects you or not, but it's on the svn.
Ok, I'll update to next version of orx to be sure it works with Ocean.
Later I will apply modifications needed by Ocean and if you added me to the "developers" (in sourceforge) I'll add a branch.
ORX 1.3 Ocean variant and Ocean source codes are available in the branches folder of svn.
I'd like to see modification in the ORX 1.3 Ocean Variant to be applied to the trunk but that needs approval of iarwain as the modifications i've done could be against original ORX philosophy.
As a good start, Ocean sourcecode is uncomplete, buggy and uncommented.
There are a lot of nasty things to fix but I had just the time to write code to have a pseudo-working editor for my businness.
The solution is for VS2010 and you need .NET 4.0 and ORX 1.3 Ocean variant.
Once downloaded the orx 1.3 ocean variant you have to compile orx ocean variant with dotNet_Debug/Release configurations.
After compiling the orx ocean variant, you have to declare an environment variable called ORX_PATH that points to the "code" folder under the orx folder.
Now you can open Ocean solution.
OceanBase project has a link to orx.dll and it must be updated to the one you just compiled. You can find it in $(ORX_PATH)libdynamic.
At this point everything should compile.
Ehmm....coff...coff...as of now, it works only in debug because...well...I don't know but I just discovered that.
I'll fix asap.
If you have problems building the sourcecode or you want to help me and need more details on the mess I've done, just drop me some lines.
I'm not sure to be able to answer soon but I'll do what I can.
Is it possible to create new rendereable objects that are not orxOBJECTs?
Let's make an example.
Think about creating an orxLine object with it's configuration parameters, it's orxSTRUCTURE_ID entry and let the renderer module to call orxDisplay_DrawLine.
Or, in alternative, an orxOBJECT with a "type" field that helps the engine to recognize it's a "line" and so it reads other configuration keys to get the start and end vector.
As an object it should use joints, body and so on...but animations would be made only sequences of coordinates instead of graphics.
Once done this first "vectorial" object, i'd like to know is if it would be possible to add new functionalities like DrawArc, DrawEllipse, FillRect (with gradient) and so on.
This could be a good base for who wants to implement a vectorial library and could help as base for a GUI project (that I'm trying to insert into ORX).
I'll check your changes next week end. I don't have vs2010 though, so I will see if I cab get enough time for making a vs2008 project for Ocean and trying it.
Adding a primitive type structure could be done (and then linking it to orxGRAPHIC).
As for going to fully support a vectorial approach, I don't think that will be happening based on the primitives I wrote as they are pretty limited (basic features only, no AA, no batch rendering for now, ...) and are more intended for very simple drawing/debug display.
I intend to add DrawPolyline and DrawEllipse could be a good addition too. As for FillRect that would be more an addition to the DrawOBox I think.
Anyway, if you need a real vector drawing support I think cairo and such as the real way to go. Probably via a plugin or by extending the display ones.
Also vector rendering is probably too costly for a bunch of iOS/Android devices out there and doing a pre-render on texture is probably the way to go there. With the skeletal animation support that will come soon-ish, that should work perfectly fine.
Actually I'm a bit confused on the direction to take with Ocean development.
Yesterday I thought about a good improvement that could lead to have a nice all-around editor for physics and scenes without need of a fixed engine as a target.
I started using ORX in Ocean because it was a way to learn more about the engine and a way to build the editor in the same time.
Thinking about the state of the art, I'm using very little features of ORX and I'm trying to add new features to ORX that are not game oriented but more editor oriented...while ORX is game oriented.
I made tricks to adapt ORX to an environment that's not the one it was studied for and not all the tricks are working well and they are not "clean".
The code I wrote is a mess because is lacking of a study...because it started as a proof of concept but needs a deep interventions.
There are few unlucky decision I made that are blocking me from concentrating on new features and one is to work directly with the ORX ini files/architecture.
So, at the end of my thoughts I'm evaluating other options and an architectural review.
I'm thinking is to stop using ORX inside Ocean and substitute it with a custom control that handles image drawing and layers.
Stop using ini files and use a binary file format (like it was in the beginning).
Add a plugin architecture to export project data into different formats. The first plugin will be for ORX.
Add a "Play/Stop" button that exports data for the selected engine and launches an external application (ex: an ORX application) that shows how the scene looks in the real engine.
In that way the editor can be adapted to other engines without being limited by engine features.
I will think more about that but for now I think it's the best solution.
What do you think about that?
That's a tough question. On paper building an engine-agnostic editor looks like the way to go.
But in reality I don't know if that's the best idea ever for a simple reason: all the available engines out there are very different, in term of features or data inputs, for example.
If you take orx animation graph for example, it's a very unique feature you won't find anywhere else, so it would be entirely part of the plugin I guess. But in that case that'd mean that the core part of the editor would be a very simple and straightforward framework.
Unless you focus on very specific parts of edition, such as writing a map editor, but I don't think that's your goal, is it?
Another great thing with editors is the ability of modifying the content while you're playing. And with the approach you're mentioning you'd lose such a benefit. That being said, supporting such a feature isn't that easy to begin with, so if you didn't intend to go that way, you wouldn't lose anything.
I'm probably not seeing the big picture there, nor do I know precisely your goals, so I can only give my point of view here.
What I have in mind is to have full flexibility to add features to the editor.
For example...I'd like to add drawings of joints to know exactly where they are and how they act. I'd like to use vectorial drawings to draw such objects.
The same for spawners.
I'd like to add new objects like triggers, paths, gui controls and so on.
That said, I think it would be easier (and less time consuming) to do that with a custom control instead of using ORX.
The editor I'm trying to do is more like a "Visual Studio for Game Engine" editor.
You edit contents as you edit sources. Then you compile and test.
My goal it to have a tool to create a project containing all informations needed by a game engine.
I want to be able to draw scenes with layers, place objects in a map, define the kind of animations the objects can do, add sounds for objects and music for the scenes, add gui objects, add fonts/text and localization helpers and physics editor too.
I want to be able to export all contents for ORX or for any other engine that needs an editor like that.
I could do the same using ORX inside Ocean but for me it takes more time than using a custom control for static drawing.
What I miss more the the opportunity to directly draw into the editor view with something similar to GDI.
With ORX all must be a stretched bitmap. While this is perfect for runtime, it's not for the kind of editor I mean.
About the animation graph:
I think the way orx uses animations is really great. Well, I think the way orx is done is great!.
For that reason the internal structure of the editor will be close to the one used by orx, expecially for animations and the animation transitions.
If other engines have a different way to handle animations I think it will be not a problem to write a nice exporter plugin because in ORX structure (or the close imitiation of Ocean) there will be all information needed.
That said, I want to think more about that before make any modification.
What I have in mind is to have full flexibility to add features to the editor.
For example...I'd like to add drawings of joints to know exactly where they are and how they act. I'd like to use vectorial drawings to draw such objects.
The same for spawners.
I'd like to add new objects like triggers, paths, gui controls and so on.
That said, I think it would be easier (and less time consuming) to do that with a custom control instead of using ORX.
That's probably true. (Well, except for physics display as soon I'll have Box2D own display system hooked up in orx. )
The editor I'm trying to do is more like a "Visual Studio for Game Engine" editor.
You edit contents as you edit sources. Then you compile and test.
My goal it to have a tool to create a project containing all informations needed by a game engine.
That's where I think things might get a bit more tricky. Game engines can have wildly different features and maintaining the set of tools/features available for engine X or Y while editing can become a huge task.
I want to be able to draw scenes with layers, place objects in a map, define the kind of animations the objects can do, add sounds for objects and music for the scenes, add gui objects, add fonts/text and localization helpers and physics editor too.
That sounds great if not a bit ambitious.
I want to be able to export all contents for ORX or for any other engine that needs an editor like that.
I could do the same using ORX inside Ocean but for me it takes more time than using a custom control for static drawing.
What I miss more the the opportunity to directly draw into the editor view with something similar to GDI.
With ORX all must be a stretched bitmap. While this is perfect for runtime, it's not for the kind of editor I mean.
No, that's definitely a big limitation for the kind of display you need.
But if you go with an editor display only, you will get the opposite issue: you won't be able to represent things how they'll look into a game engine, and then the users will have to do back and forth every time they try to modify or tweak the properties of an object so that they can actually see how it'll look in-game.
Sure there are features that are likely to be common by most engines, like applying a teint or an alpha. Or even tiling or mirroring. But then come blending mode, anti aliasing modes, visual FXs, shaders, custom rendering, including 3D one, etc...
And that will not be rendered correctly - if at all - in the editor unless you rewrite everything related to display/rendering yourself (which is already a huge task for one single engine let alone many).
Otherwise that will require the users to constantly save and start the game, go to the place they want to test (might take many minutes in-game to get there) whenever they're setting or tweaking backgrounds, lighting or overall ambiance.
I think the best option is actually a mix: let the engine draw game content and use your own direct drawing for editor content.
Instead of embedding the engine window and have everything rendered by it, you can ask the engine to render to a texture instead.
If you start the engine in a separate thread inside the editor process, you could get the texture content directly from memory or, worst case scenario, have it sent via named pipes in the case of separate process.
About the animation graph:
I think the way orx uses animations is really great. Well, I think the way orx is done is great!.
For that reason the internal structure of the editor will be close to the one used by orx, expecially for animations and the animation transitions.
If other engines have a different way to handle animations I think it will be not a problem to write a nice exporter plugin because in ORX structure (or the close imitiation of Ocean) there will be all information needed.
Maybe. I'm a bit more skeptical about that part but it might be something that can be solved, I don't know.
It's just that if an engine is missing a feature, like the animation graph for example. Whatever you export won't be handled by the engine at all. Unless you extend the engine yourself with that feature with writing a runtime layer that users will have to use on top of the engine, maybe?
That said, I want to think more about that before make any modification.
Sorry for loooooong absence from the forum and from Ocean project but I had a really busy time and I had to stop development of all home projects.
In these days I'm trying to re-start with development of the editor and my game coding.
I saw that a lot of people is trying to make usefull editors for the orx engine.
I see a lot of projects like the animation editor, tile map editor exporters and other utilities that I see as nice features for an "Orx Studio" project.
What about joining our efforts to build a single project to mantain?
A cross-platorfom one, driven by plugins, made in c# or Java or something portable...
I made a basic architecture in c# to handle every aspect of orx game engine, but as soon as I modified the architecure I had to stop.
I saw the animation editor of enobayram is better than what I was trying to implement, Reemon's physic editor is the part that I was thinking to add to make the editor "complete".
Ocean looks amazing, and I'd love to integrate the Orx Animation Editor (Can I squat over this name officially ) in it, while maintaining a stand-alone version as well. I was planning to somehow integrate Orx into the animation editor in the very long run, but I actually wanted to do that to implement features that Ocean already seems to do much better. I think an integration like this would be a win-win for all of us tool developers and the Orx community!
I can imagine various levels of integration:
1. Ocean ships with OAE and simply invokes it on demand
2. Ocean sets up OAE so that it starts up in a convenient state to edit animations for the content inside Ocean
3. Ocean invokes OAE and talks to it over sockets, both sides notifying each other of modifications in real time.
4. Ocean manipulates OAE directly through JNI (or equivalent).
5. Ocean embeds OAE as a widget.
Whatever the level of integration, I guess we should definitely support drag and drop between the editors.
Personally, I'd prefer to go for integration level 3, as it'll probably be the most platform independent one, and 3 or 4 would be transparent to the user anyway (Plus we get distributed editing, whatever that might be useful for ). 4 would still be doable, but 5 is probably an adventure
BTW, all the integration alternatives I've mentioned go for any other plug-in as well.
thank you for your words.
I see your animation editor is made in Java and there are few opportunities to make a C#-Java interop.
If you want to integrate orx into a widget I can tell you how I've done in the first version of Ocean, but it's not portable to other platforms because there's need of a modification in orx code to allow orx to be child of a window in a clean way.
I think the nicest solution would be solution 5 but with a modification:
OAE ships as an Ocean plugin but with a loader executable that allows to load it as if it was inside Ocean.
In this way you mantain a single codebase
The main problem I see is the environment. If we decide to create a sort of 'orx studio' we need the same environment.
I'd like to write you using skype to continue with tech considerations in private without filling the forum.
I leave a screenshot of last Ocean version, that's in deep w.i.p. state
I saw that a lot of people is trying to make usefull editors for the orx engine.
I see a lot of projects like the animation editor, tile map editor exporters and other utilities that I see as nice features for an "Orx Studio" project.
What about joining our efforts to build a single project to mantain?
A cross-platorfom one, driven by plugins, made in c# or Java or something portable...
Would be great to have an "Orx Studio" instead of bunch of separate projects that might go unmaintained anytime ;-) and don't really talk to each other.
I'm all for portability being a Linux user ;-). Last time I checked Ocean was requiring .Net 4 and using some P/Invoke magic to talk to orx, so not really portable :-(.
I guess Java, Python or plain C/C++ would be easier ;-).
What about creating a little team?
Great idea. Don't count on me for C# projects though . With Java I have some experience but strictly in J2ME. That's why I started hacking on orxCraft by acksys which is written around Scroll in C++. I first started to write my own editor in Python+Qt but figured that running orx to display stuff and manage ini files will be better in the long run.
enobayram wrote:
I can imagine various levels of integration:
1. Ocean ships with OAE and simply invokes it on demand
2. Ocean sets up OAE so that it starts up in a convenient state to edit animations for the content inside Ocean
3. Ocean invokes OAE and talks to it over sockets, both sides notifying each other of modifications in real time.
4. Ocean manipulates OAE directly through JNI (or equivalent).
5. Ocean embeds OAE as a widget.
I really like #3. I had the same idea to talk to ScrollEd from an object editor. Maybe we should standardise some protocol so all tools could easily talk to each other? For starters:
- Please edit object: "Object Name"
- Ini files modified please reload
Graag, enobayram , I sent you pm with my skype contatc.
Actually Ocean uses only .NET and no more p/invoke for orx...in fact it does not uses ORX to render.
The code is not yet public because the new version it's not in a stable or working state.
I'm a Linux user too, but I consider C# as portable as Java or other kind of languages.
Java nees a Java VM, C# needs mono, C++ needs Gtk/Qk/wxWidgets...etc.
The problem is that Ocean (or our future Orx Studio) would be an application that will use a lot of UI, not just 2 or 3 buttons.
That's why we should evaluate the best environment to achieve the result in the best and quickest way.
Personally I'd prefer plugin architecture because every portion of the software can easily access the same data structure and share events about modifications of objects.
I think that polling sockets for getting events from a software that runs on the same machine as the software that receives the events...is not so efficient.
It's less efficient if we consider that the two software have to work with the same data pool.
It's less easy to implement than a call to a method in a library.
The main problem with 'big' projects is that they never end, and I think thing should be mantained as simple as possible or we will never end it.
Until now I had a lot of dreams about Ocean but I know that only a part of those dreams will become working and usable code.
I lack of time and...why not, experience too.
Comments
Sorry to hear about that but I understand all too well the lack of time.
Best of luck for now and I'm looking forward to seeing progress on Ocean when you're back on it.
Cheers!
Meanwhile, the company I work for, has intentions to start mobile dev project and I'm evaluating few possibilities.
It's possible that in the near future I'll use ORX for the project the have in mind but I need to better understand a thing.
I would integrate libRocket with ORX for Windows, iPhone and Android (well...mac and linux too).
That would be useful for Ocean, for my game, and for the company projects.
Is there anyone that can help me with that?
Thanks and bye bye
If you simply want to run libRocket on top of orx and hook it to its display, that shouldn't be too much work. If you want to integrate it at a lower level (and add a GUI plugin/module), that's going to be much more work. The actual new module/new plugin implementation part is easy, but the part where we need to define a generic way to describe UI items with orx's syntax and bridge them to libRocket is going to require a huge amount of work I think. Unless you restrict that generic interface to a strict minimum.
As of now I just finished a big modification of the core of the application but I still need to test it.
The project is still alive and I will find the time to work on it but right now I'm really busy with other things.
I will update this thread when I'll get a new version.
bye
Just a quick note to let you know that I fixed some issues with orx with respect to minimization/iconfication, especially on windows. Not sure if it affects you or not, but it's on the svn.
Later I will apply modifications needed by Ocean and if you added me to the "developers" (in sourceforge) I'll add a branch.
I sent it now by e-mail.
Bye bye
as soon as I have time to download, test and update the svn version (in a branch) I post here few raws.
Bye
It seems to work.
Right now I'm uploading the modified version into orx-1.3_Ocean folder under the branches folder (it's veeeeeeeeeeery sllllloooooow).
As soon as it finished to upload it, I publish Ocean sources under Ocean folder in branches.
Bye bye
ORX 1.3 Ocean variant and Ocean source codes are available in the branches folder of svn.
I'd like to see modification in the ORX 1.3 Ocean Variant to be applied to the trunk but that needs approval of iarwain as the modifications i've done could be against original ORX philosophy.
As a good start, Ocean sourcecode is uncomplete, buggy and uncommented.
There are a lot of nasty things to fix but I had just the time to write code to have a pseudo-working editor for my businness.
The solution is for VS2010 and you need .NET 4.0 and ORX 1.3 Ocean variant.
Once downloaded the orx 1.3 ocean variant you have to compile orx ocean variant with dotNet_Debug/Release configurations.
After compiling the orx ocean variant, you have to declare an environment variable called ORX_PATH that points to the "code" folder under the orx folder.
Now you can open Ocean solution.
OceanBase project has a link to orx.dll and it must be updated to the one you just compiled. You can find it in $(ORX_PATH)libdynamic.
At this point everything should compile.
Ehmm....coff...coff...as of now, it works only in debug because...well...I don't know but I just discovered that.
I'll fix asap.
If you have problems building the sourcecode or you want to help me and need more details on the mess I've done, just drop me some lines.
I'm not sure to be able to answer soon but I'll do what I can.
Bye bye
Let's make an example.
Think about creating an orxLine object with it's configuration parameters, it's orxSTRUCTURE_ID entry and let the renderer module to call orxDisplay_DrawLine.
Or, in alternative, an orxOBJECT with a "type" field that helps the engine to recognize it's a "line" and so it reads other configuration keys to get the start and end vector.
As an object it should use joints, body and so on...but animations would be made only sequences of coordinates instead of graphics.
Once done this first "vectorial" object, i'd like to know is if it would be possible to add new functionalities like DrawArc, DrawEllipse, FillRect (with gradient) and so on.
This could be a good base for who wants to implement a vectorial library and could help as base for a GUI project (that I'm trying to insert into ORX).
Bye bye
Adding a primitive type structure could be done (and then linking it to orxGRAPHIC).
As for going to fully support a vectorial approach, I don't think that will be happening based on the primitives I wrote as they are pretty limited (basic features only, no AA, no batch rendering for now, ...) and are more intended for very simple drawing/debug display.
I intend to add DrawPolyline and DrawEllipse could be a good addition too. As for FillRect that would be more an addition to the DrawOBox I think.
Anyway, if you need a real vector drawing support I think cairo and such as the real way to go. Probably via a plugin or by extending the display ones.
Also vector rendering is probably too costly for a bunch of iOS/Android devices out there and doing a pre-render on texture is probably the way to go there. With the skeletal animation support that will come soon-ish, that should work perfectly fine.
Yesterday I thought about a good improvement that could lead to have a nice all-around editor for physics and scenes without need of a fixed engine as a target.
I started using ORX in Ocean because it was a way to learn more about the engine and a way to build the editor in the same time.
Thinking about the state of the art, I'm using very little features of ORX and I'm trying to add new features to ORX that are not game oriented but more editor oriented...while ORX is game oriented.
I made tricks to adapt ORX to an environment that's not the one it was studied for and not all the tricks are working well and they are not "clean".
The code I wrote is a mess because is lacking of a study...because it started as a proof of concept but needs a deep interventions.
There are few unlucky decision I made that are blocking me from concentrating on new features and one is to work directly with the ORX ini files/architecture.
So, at the end of my thoughts I'm evaluating other options and an architectural review.
I'm thinking is to stop using ORX inside Ocean and substitute it with a custom control that handles image drawing and layers.
Stop using ini files and use a binary file format (like it was in the beginning).
Add a plugin architecture to export project data into different formats. The first plugin will be for ORX.
Add a "Play/Stop" button that exports data for the selected engine and launches an external application (ex: an ORX application) that shows how the scene looks in the real engine.
In that way the editor can be adapted to other engines without being limited by engine features.
I will think more about that but for now I think it's the best solution.
What do you think about that?
But in reality I don't know if that's the best idea ever for a simple reason: all the available engines out there are very different, in term of features or data inputs, for example.
If you take orx animation graph for example, it's a very unique feature you won't find anywhere else, so it would be entirely part of the plugin I guess. But in that case that'd mean that the core part of the editor would be a very simple and straightforward framework.
Unless you focus on very specific parts of edition, such as writing a map editor, but I don't think that's your goal, is it?
Another great thing with editors is the ability of modifying the content while you're playing. And with the approach you're mentioning you'd lose such a benefit. That being said, supporting such a feature isn't that easy to begin with, so if you didn't intend to go that way, you wouldn't lose anything.
I'm probably not seeing the big picture there, nor do I know precisely your goals, so I can only give my point of view here.
For example...I'd like to add drawings of joints to know exactly where they are and how they act. I'd like to use vectorial drawings to draw such objects.
The same for spawners.
I'd like to add new objects like triggers, paths, gui controls and so on.
That said, I think it would be easier (and less time consuming) to do that with a custom control instead of using ORX.
The editor I'm trying to do is more like a "Visual Studio for Game Engine" editor.
You edit contents as you edit sources. Then you compile and test.
My goal it to have a tool to create a project containing all informations needed by a game engine.
I want to be able to draw scenes with layers, place objects in a map, define the kind of animations the objects can do, add sounds for objects and music for the scenes, add gui objects, add fonts/text and localization helpers and physics editor too.
I want to be able to export all contents for ORX or for any other engine that needs an editor like that.
I could do the same using ORX inside Ocean but for me it takes more time than using a custom control for static drawing.
What I miss more the the opportunity to directly draw into the editor view with something similar to GDI.
With ORX all must be a stretched bitmap. While this is perfect for runtime, it's not for the kind of editor I mean.
About the animation graph:
I think the way orx uses animations is really great. Well, I think the way orx is done is great!.
For that reason the internal structure of the editor will be close to the one used by orx, expecially for animations and the animation transitions.
If other engines have a different way to handle animations I think it will be not a problem to write a nice exporter plugin because in ORX structure (or the close imitiation of Ocean) there will be all information needed.
That said, I want to think more about that before make any modification.
That's probably true.
That's where I think things might get a bit more tricky. Game engines can have wildly different features and maintaining the set of tools/features available for engine X or Y while editing can become a huge task.
That sounds great if not a bit ambitious.
No, that's definitely a big limitation for the kind of display you need.
But if you go with an editor display only, you will get the opposite issue: you won't be able to represent things how they'll look into a game engine, and then the users will have to do back and forth every time they try to modify or tweak the properties of an object so that they can actually see how it'll look in-game.
Sure there are features that are likely to be common by most engines, like applying a teint or an alpha. Or even tiling or mirroring. But then come blending mode, anti aliasing modes, visual FXs, shaders, custom rendering, including 3D one, etc...
And that will not be rendered correctly - if at all - in the editor unless you rewrite everything related to display/rendering yourself (which is already a huge task for one single engine let alone many).
Otherwise that will require the users to constantly save and start the game, go to the place they want to test (might take many minutes in-game to get there) whenever they're setting or tweaking backgrounds, lighting or overall ambiance.
I think the best option is actually a mix: let the engine draw game content and use your own direct drawing for editor content.
Instead of embedding the engine window and have everything rendered by it, you can ask the engine to render to a texture instead.
If you start the engine in a separate thread inside the editor process, you could get the texture content directly from memory or, worst case scenario, have it sent via named pipes in the case of separate process.
Maybe. I'm a bit more skeptical about that part but it might be something that can be solved, I don't know.
It's just that if an engine is missing a feature, like the animation graph for example. Whatever you export won't be handled by the engine at all. Unless you extend the engine yourself with that feature with writing a runtime layer that users will have to use on top of the engine, maybe?
I'm afraid I can't be of much help there, sorry!
In these days I'm trying to re-start with development of the editor and my game coding.
I saw that a lot of people is trying to make usefull editors for the orx engine.
I see a lot of projects like the animation editor, tile map editor exporters and other utilities that I see as nice features for an "Orx Studio" project.
What about joining our efforts to build a single project to mantain?
A cross-platorfom one, driven by plugins, made in c# or Java or something portable...
I made a basic architecture in c# to handle every aspect of orx game engine, but as soon as I modified the architecure I had to stop.
I saw the animation editor of enobayram is better than what I was trying to implement, Reemon's physic editor is the part that I was thinking to add to make the editor "complete".
What about creating a little team?
Ocean looks amazing, and I'd love to integrate the Orx Animation Editor (Can I squat over this name officially
I can imagine various levels of integration:
1. Ocean ships with OAE and simply invokes it on demand
2. Ocean sets up OAE so that it starts up in a convenient state to edit animations for the content inside Ocean
3. Ocean invokes OAE and talks to it over sockets, both sides notifying each other of modifications in real time.
4. Ocean manipulates OAE directly through JNI (or equivalent).
5. Ocean embeds OAE as a widget.
Whatever the level of integration, I guess we should definitely support drag and drop between the editors.
Personally, I'd prefer to go for integration level 3, as it'll probably be the most platform independent one, and 3 or 4 would be transparent to the user anyway (Plus we get distributed editing, whatever that might be useful for
BTW, all the integration alternatives I've mentioned go for any other plug-in as well.
I'm all in for the team
thank you for your words.
I see your animation editor is made in Java and there are few opportunities to make a C#-Java interop.
If you want to integrate orx into a widget I can tell you how I've done in the first version of Ocean, but it's not portable to other platforms because there's need of a modification in orx code to allow orx to be child of a window in a clean way.
I think the nicest solution would be solution 5 but with a modification:
OAE ships as an Ocean plugin but with a loader executable that allows to load it as if it was inside Ocean.
In this way you mantain a single codebase
The main problem I see is the environment. If we decide to create a sort of 'orx studio' we need the same environment.
I'd like to write you using skype to continue with tech considerations in private without filling the forum.
I leave a screenshot of last Ocean version, that's in deep w.i.p. state
Would be great to have an "Orx Studio" instead of bunch of separate projects that might go unmaintained anytime ;-) and don't really talk to each other.
I'm all for portability being a Linux user ;-). Last time I checked Ocean was requiring .Net 4 and using some P/Invoke magic to talk to orx, so not really portable :-(.
I guess Java, Python or plain C/C++ would be easier ;-).
Great idea. Don't count on me for C# projects though
enobayram wrote:
I really like #3. I had the same idea to talk to ScrollEd from an object editor. Maybe we should standardise some protocol so all tools could easily talk to each other? For starters:
- Please edit object: "Object Name"
- Ini files modified please reload
Cheers,
Graag
Actually Ocean uses only .NET and no more p/invoke for orx...in fact it does not uses ORX to render.
The code is not yet public because the new version it's not in a stable or working state.
I'm a Linux user too, but I consider C# as portable as Java or other kind of languages.
Java nees a Java VM, C# needs mono, C++ needs Gtk/Qk/wxWidgets...etc.
The problem is that Ocean (or our future Orx Studio) would be an application that will use a lot of UI, not just 2 or 3 buttons.
That's why we should evaluate the best environment to achieve the result in the best and quickest way.
Personally I'd prefer plugin architecture because every portion of the software can easily access the same data structure and share events about modifications of objects.
I think that polling sockets for getting events from a software that runs on the same machine as the software that receives the events...is not so efficient.
It's less efficient if we consider that the two software have to work with the same data pool.
It's less easy to implement than a call to a method in a library.
The main problem with 'big' projects is that they never end, and I think thing should be mantained as simple as possible or we will never end it.
Until now I had a lot of dreams about Ocean but I know that only a part of those dreams will become working and usable code.
I lack of time and...why not, experience too.
Bye
Ocean development will be officially closed to leave space to Orx Studio.
You can follow and partecipate the discussion on the dedicated thread.
Greetings,
ainvar