Ocean (An Orx Content Editor)

edited November 2011 in Projects - Tools
Hi people,

here's a screenshot of the current state of the Ocean editor.

I'm just using it a bit to discover first bugs (there are many :blush: ) and soon i'll release the source code on svn.

As of now I've done a wizard to create animations with few clicks and add sequential frames just by clicking on a grid on images.
As soon as I have time i'll add a helper for animation links.



OceanPreRelease.jpg


Bye bye
«1

Comments

  • edited November 2011
    That looks pretty cool. Good luck!
  • edited November 2011
    This is awesome! Keep it up. To say a content editor would be so useful, is an understatement.
  • edited November 2011
    Looks great!!

    I would love to help test.
  • edited November 2011
    Looking very nice, congrats!

    Also, do you hardcode the list of properties or do you use the CreationTemplate.ini as an input?
  • edited November 2011
    Thank you all for your comments. I hope the project will grow more in the future and I'll really appreciate your help.

    #iarwain:
    I created a class for each entity and the class is based on a base class OceanBaseObject that exposes it's properties in a list.
    To answer your question...yes, it's hardcoded and I don't use the CreationTemplate.ini because it's more difficult to handle thinks like that:

    Pivot = center(+truncate|round)|left|right|top|bottom|[Vector];

    I need to assign a value and then call orxObject_SetPivot to show the effect on the scree...so for me it's more easy to know what's a pivot and define the list of values it can have.

    Well...i took a bad example because actually pivot is semi-working :)
  • edited November 2011
    ainvar wrote:
    Pivot = center(+truncate|round)|left|right|top|bottom|[Vector];

    That's probably the most complex line in the whole file. :) But nothing that can't be easily analyzed by a regular expression.
    I've tried to always use the same syntax in the whole file but I can rewrite some more complex expressions such as this one if need be. This one could definitely be written in a better way.
  • edited November 2011
    I don't see the advantage, for Ocean, to read the CreationTemplate.ini file.
    If you add a new property it could be automatically shown in the property list but I still have to handle the property value changes to make orx to apply the value to a living object...so at the end, if I need to write code to handle the new property I can add the property to classes I've done.

    Talking about orx feature i'm badly missing :)....

    I'd like to show a grid on the screen and to be able to draw primitives (lines, circle, squares and triangles).

    The grid will be used for "snap to grid" features (actually i'm debugging the "snap to nearest object" feature).
    The shapes will be used to show directions (spawners), applied forces, etc...
    It would be a nice thing to have it in GLFW and ORX instead of creating orx objects and scale them.

    If nobody can do that I'll try to do it by myself when i'll have time (and when the editor will be more usable).
  • edited November 2011
    ainvar wrote:
    I don't see the advantage, for Ocean, to read the CreationTemplate.ini file.
    If you add a new property it could be automatically shown in the property list but I still have to handle the property value changes to make orx to apply the value to a living object...so at the end, if I need to write code to handle the new property I can add the property to classes I've done.

    Well, yes and no. :)

    An easy work around is to actually delete/recreate the object upon modification in config, this way you don't need any glue code for patching objects on-the-fly and the update code becomes generic.

    The other option, much better, is on my todo list: the config module will fire a "modified" event for a field, then this would get intercepted by orx structures to update themselves if need be. But it was merely a suggestion for now, I can let you know when I've added the "hotloading" feature. Don't expect it too soon though, it's not very high on my todo list. :)
    Talking about orx feature i'm badly missing :)....

    I'd like to show a grid on the screen and to be able to draw primitives (lines, circle, squares and triangles).

    The grid will be used for "snap to grid" features (actually i'm debugging the "snap to nearest object" feature).
    The shapes will be used to show directions (spawners), applied forces, etc...
    It would be a nice thing to have it in GLFW and ORX instead of creating orx objects and scale them.

    Those are also on my todo list. Till some primitives are added, depending on the shapes I need, I either go with a shader (like the grid I'm using in ScrollEd which is a very basic object+shader, all done in config) or by using a couple of different workarounds.

    For lines I either use stretched objects with the pixel texture or directly issue orxDisplay_* calls on a placeholder object (to gets the render hooks).
    For more complex things, especially when there are many, I sometimes create a procedural texture, do my custom rendering in it (CPU-side) and use it as texture in my placeholder object.

    If all this is confusing, please let me know, I'll try to add a wiki entry as a trick for rendering non-bitmap data things.

    If nobody can do that I'll try to do it by myself when i'll have time (and when the editor will be more usable).

    That'd be nice, but it's a slightly more tricky than it sounds: you can't rely on any direct mode as it's a legacy that'll be removed from OpenGL soon (and already been removed from OpenGL ES).
  • edited November 2011
    iarwain wrote:
    Well, yes and no. :)

    An easy work around is to actually delete/recreate the object upon modification in config, this way you don't need any glue code for patching objects on-the-fly and the update code becomes generic.

    The other option, much better, is on my todo list: the config module will fire a "modified" event for a field, then this would get intercepted by orx structures to update themselves if need be. But it was merely a suggestion for now, I can let you know when I've added the "hotloading" feature. Don't expect it too soon though, it's not very high on my todo list. :)

    That's what I've implemented in the editor. As soon as a property is modified, the orx structure is updated and I check in all the project tree to see if there are orphans or any other object that needs modifications. If needed I destroy and re-create the object.

    Those are also on my todo list. Till some primitives are added, depending on the shapes I need, I either go with a shader (like the grid I'm using in ScrollEd which is a very basic object+shader, all done in config) or by using a couple of different workarounds.

    For lines I either use stretched objects with the pixel texture or directly issue orxDisplay_* calls on a placeholder object (to gets the render hooks).
    For more complex things, especially when there are many, I sometimes create a procedural texture, do my custom rendering in it (CPU-side) and use it as texture in my placeholder object.

    If all this is confusing, please let me know, I'll try to add a wiki entry as a trick for rendering non-bitmap data things.

    Ehm... :blush:
    Yes, I would appreciate a lot the wiki option. I really have to dig inside the shaders.
    I know what they are but, since I suffer technological inertia ,I have to get used to think about shaders advantages. :laugh:

    That'd be nice, but it's a slightly more tricky than it sounds: you can't rely on any direct mode as it's a legacy that'll be removed from OpenGL soon (and already been removed from OpenGL ES).

    Uh? Really? :(
    That would be the needed force to win my technological inertia. :)
  • edited November 2011
    Ehm...coff...coff.
    Where can I find ScrollEd sources?
  • edited November 2011
    Well actually the removal of direct mode already happened 2 years ago in OpenGL 3.1 (the latest specs being OpenGL 4.2) but many projects out there are still using an older version. :)

    As for Scroll(Ed) sources, it's on invitation only! ;)
    Well there's actually a thread on it in the forum started by faistoiplaisir but I don't know if there's a link to a recent version in it.
    You can contact me at iarwain (@ this domain) so that I can get your email address and I'll send you an up-to-date version tonight (I'm at work right now).

    And you'll see, shaders (especially fragment/pixel ones) are actually pretty simple and easy to write. If you're familiar with old 2D rendering it'll feel eerily familiar. :)

    I'll try to write the wiki entry next week end. :)
  • edited November 2011
    Mail sent.

    Here it's 00.03 AM so i think I will read it tomorrow :)
  • edited November 2011
    Update:

    Here's another screenshot of the editor. You'll see something new in the preview window (the Orx one).

    - Added Snap to nearest Layer object
    - Added Snap to nearest Scene object
    - Added Snap to grid
    - Added Grid (10x10 px)
    - Added Tile mode (tile with mouse)

    @iarwain: Before you ask, I answer.
    No, the grid is not a shader because I wasn't able to modify the shader of ScrollEd to my needs.
    I still have problems understanding shaders, how to write them and how to debug.
    During xmas holidays I will study shaders and if someone has a tutorial for dummies I will appreciate :)

    Next features in todo list:
    - Multiple selection/move/snap
    - Better save-files organization
    - Better animation wizard
    - Animation preview in orx window.
    - Sound preview
    - Compact UI with owner draw controls (tree, text box, ....)
    - Editor preferences dialog

    Maybe tomorrow i'll release an executable for people who want to start to laugh for the amount of bugs in the editor :P

    Bye bye

    screenshot121111.png
  • edited November 2011
    Looks great! B)
  • edited November 2011
    Here's a test executable.
    You can create a graphic, animations and template objects.
    You can create screens, layers and insert object instances into layes.

    Let me know what you think. It's still a w.i.p. so you have to expect a lot of bugs, misfunctionings and incredibly nasty stuff.

    Enjoy. https://forum.orx-project.org/uploads/legacy/fbfiles/files/Ocean_v0.zip
    Ocean_v0 760.4K
  • edited November 2011
    Nice!

    I'll try to give it a try next week end. My home computer time is almost nonexistent lately during the week.
  • edited November 2011
    No problem, I understand the situation. Me too, for a while, I have to decrease the amount of time dedicated to home development.
  • edited November 2011
    Hi,

    I would like to test your editor but It seems there's a problem. Your .exe crash immediatly.

    I have try on my w7 64 bits and on a XP 32 bits.

    On XP, I have a message box before crash that tell me to download the .Net Framework 4 and even by doing that, the software is crashing.

    There's something missing in your .zip ? It crash only for me ?

    Thanks !
  • edited November 2011
    I can run it. Windows 7 x86, .NET Framework 4.

    This is a dev machine, so I also have Visual Studio installed and all that comes with it... Windows SDK, etc.
  • edited November 2011
    faistoiplaisir wrote:
    Hi,

    I would like to test your editor but It seems there's a problem. Your .exe crash immediatly.

    I have try on my w7 64 bits and on a XP 32 bits.

    On XP, I have a message box before crash that tell me to download the .Net Framework 4 and even by doing that, the software is crashing.

    There's something missing in your .zip ? It crash only for me ?

    Thanks !

    Hello,

    I checked dependencies and it seems all right. The only thing that comes to my mind is that the orx.dll I use is a modified one.

    Did you use the one I put in the zip?
  • edited November 2011
    To run the executable you'll need to install 2 things.

    - .NET Framework 4
    - Microsoft Visual C++ 2010 Redistributable Package

    Hope this helps.
  • edited November 2011
    Hi all,

    Ok, the problem was "Microsoft Visual C++ 2010 Redistributable Package" ...

    After install it, there's no problem !

    So perfect !

    Now I just have to test it a little !

    Thanks !
  • edited November 2011
    Well, well, well!

    If you have questions about usage don't hesistate.

    All you have to do is to start with the object editor (ctrl+shift+O) and add a new object. When you click on a property button you specify that the current entity overrides the possible parent entity (if it inherits from a parent).
    To enable the Graphic property you have to click on "Graphic" (and it becomes blue) then select a graphic from the list.
    If you want to add an entity to the list you have to click "+".

    As of now you can edit only objects and graphics and animations. May be some other object too but I did not test.

    In the main window you can zoom (ctrl +/ctrl -) and move the object using different options.
    Free move: after selection you can move the object freely.
    Snap to scene object: when you move the object is auto aligned with nearest object border coordinate.
    Snap to layer: same as snap to scene object but the reference objects are the ones belonging to the same layer as the selected object.
    Snap to grid: well, it snaps to grid :)
    Tile: it's not a movement...it changes scale and repeat values of the object instance to duplicate it.
  • edited November 2011
    Hi,

    I just test Ocean a little and I think it can be very usefull ! You've done a good job until now !

    But, for sure, there's a lot of thing to do again.

    I do a quick post because I have to leave now, but I would like to know how you want to use the generated .ini files and the behaviour of all objects.

    Actually, in my games, I program all the code using my C++ code. In the futur, what do you want to do with ocean ? It's a tool to generate .ini files only, or you want to integrate a scriting engine or something like that ?

    I think, having the 2 possibilities will be a good point. I'm not sure to want a scriting engine, so in my case, maybe I prefer using ocean as a config editor. Maybe someone want to process all the developpment using ocean, I don't know. What's your opinion on that ?

    Actually, you make an editor that require a "knowledge" of the orx .ini file. I say that because all settings are directly linked to a config value. If you want to create an object, you have to create a graphic, etc ... I need to think more but my first opinion is to "hide" a maximum of properties, or show them differently, so a designer can setup himself an object.

    For exemple, actually there's an editor with all available Graphics in the game. When you want to create an object, you have to select the graphic in this list (so graphic has to be created before).
    My first idea was to first create the object and in the object properties, select a bitmap. By default, the real 'graphic' will be hidden. If you want more details, like entering texture coord, you can view that in the "advanced settings". But, again, without showing the existence of a graphic in the config.

    You understand what I want to say ? It make sense ?

    I have to leave, so it was just to make a first comment !

    I'm really curious to see how you program the core of your editor, you don't want to host it in a svn ? ;)

    Cheers !
  • edited November 2011
    Thank you for the comment.

    I agree with all you said.
    The first step in my development is to give all functionalities for the ORX programmer and not for the designer.
    That's needed by me to better understand how orx works and to understand where modifications are needed to make a fast & complete flow while editing contents.

    Today I modified few things and now all parameters can be edited, joints, body parts, effects, shaders...and so on.
    Now I have to finish a core modification and then I'll leave a second executable for test.

    Then I will start the second step of the development.

    About your questions:
    In my mind the future of the editor is quite clear. One day, may be on step 3 of the development, I'll create game templates to speed up development of "standard" games.
    Let's say you want to create a platform, you tell Ocean you want to do a platform game, create the contents, levels and, after definig the "hero", you can test gameplay directly in the editor window.
    That's what I dream...but what I dream is an evolution of what I need.

    Actually, what I need is a basic contents editor to insert data and create levels. That's why I started with a basic ini creator.

    I totally understand your example and it makes sense to me..it's something I'm thinking about but fot now I'd like to end step 1. The basics.

    After ending step 1 I have to clean up few spaghetti code blocks and insert few comments where needed.
    Then all contents will be in svn.

    I hope tomorrow to release another test executable.

    Stay tuned!
  • edited November 2011
    I understand your steps and it's normal.

    For me, to understand something, the only one solution, is to use it.

    You said that you want to have a better understanding of orx, cool, you're right. But I think that since you have modified the orx source code to achieve your need to create ocean (you made your own orx.dll version for ocean), you have the skill to understand a lot.

    Did you try to create a little game with orx ? If not, I suggest you to do that. You can see it in action, see its behaviour/mecanism. It's good and necessary to make a tool over it.

    Did you take a look a Scroll ? The thin C++ layer that Iarwain made over orx ? I love it and I began working with orx with this layer. For me, it's impossible to work without that helper. I think you have to take a look at that. Iarwain wrote orx from the beginning, he knows perfectly his engine, and he has a great development skill, so really, I suggest you to take a look a that, for sure, you will learn essential orx's tricks.

    And in my mind, I'm sure you have to use scroll to develop ocean (I've a little doubt only because I haven't see you code).

    So, now, as I said you in a private message, I'm drunk, and I have to sleep ^^ We will talk later about all of that !

    Cheers.
  • edited November 2011
    Hi,

    yes I took a look to Scroll, and I saw it's a good helper when coding in C++ for a game.

    I can't use scroll to develop Ocean because Ocean is 99% C# code that interfaces the modified orx library.
    The modifications I've done are just to help orx integration in a .NET application (child windows and calling conventions).
    I've added a function to get the list of objects "under" a certain point, similar to orxObject_Pick but for more objects.

    I understood how orx works because I had to study/debug it...and I agree with you...iarwain has great dev skills! Even without comments the code would be completely understandable and the design is really clear. I like it.

    Well...right now I ended the a long core modification and I'm tired.
    I need to test more deeply, but in this version it's possible to edit all parameters, even body, joints, etc...
    There is no logic behind some editing windows. For example if you edit a Joint when you change the joint type you see all parameter of joints, not only the parameters needed by the selected joint type.
    I'll fix it...one day :)

    I modified the way files are saved and that means the test project in the last zip file is no more valid.
    I included in the zip a new test project with the new format.

    When editing sounds it's possibile to hear the file by pressing right button on the button you press to select the sound/music file.

    I modified the way the grid created. Noy it's dynamic. In editor preferences dialog it's possible to set the grid size.

    Hope something works :)

    Bye https://forum.orx-project.org/uploads/legacy/fbfiles/files/Ocean_v0-2a90c73ef6357dda8fdeca943a62c7dc.zip
  • edited November 2011
    Hi,

    A question, because you're doing that editor using C#, you wrote a wrapper for each orx function to call them from C# ?

    How it works ?

    About version of your format, I suggest you to serialize at the minimum a "current version" in your format, so when you open an old project, you can load it and set new information with their default value. But, I say that "for the next step", actually, since there's no "official release", there's no need for that.
  • edited November 2011
    Hi,

    to import a function you have to declare a DllImport.
    Here's an example:

    [DllImport(ORX_DLL_NAME, CharSet = CharSet.Ansi,CallingConvention = CallingConvention.Cdecl)]
    public static extern IntPtr orxObject_CreateFromConfig(string _zConfigID);

    If you need to use structures you have to declare a structure:

    [StructLayout(LayoutKind.Explicit)]
    public struct orxVECTOR
    {
    [FieldOffset(0)]
    public float fX;
    [FieldOffset(4)]
    public float fY;
    [FieldOffset(8)]
    public float fZ;
    };

    and then declare the function import:

    [DllImport(ORX_DLL_NAME, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
    public static extern IntPtr orxMouse_GetPosition(ref orxVECTOR _pvPosition);


    Since C# does not support __fastcall i had to modify the calling convention of exported orx api to __cdecl. It's slower but nothing noticeable in an editor.
    I'd say the C# way works well, condidering that I've done that for an editor and not for a game. I've done some wrapper classes for objects, camera and viewport...but I think morx has better examples.

    For the format version it's not a problem...before I had a format that was not flexible, now I specify needed files directly in opr file.

    Today I spent a bit of time thinking about step 2 and I have some ideas...but before proceeding I want to debug as much as possible the current editor features.
    That's where the community can help a lot :)

    Did you (community) have any troubles using the editor? Misfunctionings? Ugly stuff?
  • edited December 2011
    Hi all,

    just few lines to say the project is in pause due to the short time I have in this moment.
    Daily job is really time consuming because we have to close some important activities before the end of the year.

    Sorry, I have to wait xmas holidays to continue and release it.

    I'll keep you updated.

    Bye bye
  • edited December 2011
    Hi ainvar,

    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!
  • edited January 2012
    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.

    Is there anyone that can help me with that?

    Thanks and bye bye
  • edited January 2012
    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.
  • edited January 2012
    The first one you said :)
  • edited January 2012
    You chose wisely. :)
  • edited February 2012
    Ocean is a really great tool :) Hope you'll find enough time to work on it.
  • edited February 2012
    Thank you very much.

    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
  • edited February 2012
    Hi ainvar!

    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. :)
  • edited February 2012
    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.
  • edited February 2012
    Sure, but I still don't have your sourceforge ID and ainvar on sf.net doesn't look like it's you. =)
  • edited February 2012
    Sorry, I thought I sent you the ID on a past e-mail...
    I sent it now by e-mail.

    Bye bye
  • edited February 2012
    Access granted! :)
  • edited February 2012
    Thanks,

    as soon as I have time to download, test and update the svn version (in a branch) I post here few raws.

    Bye
  • edited February 2012
    I downloaded the svn version and applied my modifications.
    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
  • edited February 2012
    Ok people,

    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
  • edited February 2012
    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).

    Bye bye
  • edited February 2012
    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.
  • edited February 2012
    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?
  • edited February 2012
    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. :)
  • edited February 2012
    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.
Sign In or Register to comment.