Orx Studio



  • edited October 2012
    Thanks for the update.

    Also, can't remember exactly who made that remark (Mhyre? Grey? someone else?), but orxNET (or orx.NET) sounds more .NET-like than NetOrx (which sounds more like a network-augmented version of orx).
  • edited October 2012

    to me orx.net, when pronounced, sounds more like arpanet, internet, ethernet, orxnet...:)

    Maybe we'll find a nice name when it will be ready to use.

    For now me and Grey have found that there are still problems with delegate relocation.
    We hope to fix it soon.

    @iarwain: do you have any news about the plugin modification?
    I was thinking it would be nice to have the opportunity to set a callback called when a plugin is loaded. In this way it would be easy to substitute the table entry points with new ones.
    To us I would mean we could even create pure C# plugins :)
  • edited October 2012
    Personally I think orx.net is better

    "Orx dot net" which kinda says exactly what it is -- orx, in .net

    but that's just my 2cents ^_^
  • edited October 2012
    ainvar wrote:

    to me orx.net, when pronounced, sounds more like arpanet, internet, ethernet, orxnet...:)

    Well, that's the thing, like any .NET software, and as Grey pointed out, it's "dot net", not "net". =)
    Plus, following the established convention, it should be orx.NET, not orx.net, but that's nitpicking. ;)
    @iarwain: do you have any news about the plugin modification?

    Mmh, which modifications are we talking about? I thought you went for an un-intrusive approach?
    I was thinking it would be nice to have the opportunity to set a callback called when a plugin is loaded. In this way it would be easy to substitute the table entry points with new ones.
    To us I would mean we could even create pure C# plugins :)

    I have to admit I'm not sure what you mean by pure C# plugins.

    Also I don't see the point in having plugin load notification as in a classic scenario you won't be able to register an event listener between the time the event module is loaded and the time where the plugins are loaded. So firing an event there will not be listened anywhere.

    Why don't do whatever you need to do when reaching the main init function? At that point plugins are loaded.
    If you want to check if a plugin is loaded, that can also be done during execution in your run function.

    Lastly, if you really need to know when your plugin is getting loaded, you can use the Plugin_Init function of the plugin itself.
  • edited October 2012
    I'm talking about this:


    What I would is to have a Fake[Keyb|mouse|joy|display]GlfwPlugin.dll and a way to make orx to use it before loading the [Keyb|mouse|joy|display] plugins.

    If you remember, we talked about the fact that plugins can't be hot-plugged when orx is compiled in embedded mode.
    That's what would be needed to make things to work.

    What I've done now is to write a fake GLFW.dll that substitutes the original one but i'd like to mantain the original glfw.dll and hot-plug a new set of plugins.

    and...we'll see to change the name. :)
  • edited October 2012
    Sorry for being a bit late on this one, for some reason I missed your answer...

    Why don't you use the non-embedded version instead then?
  • edited November 2012
    Sorry, I did not check the forum for a while.

    I don't use the non-embedded version because I'd like to use the existing orx version the user has on it's pc.
    That means that there would be no need to rebuild orx or orxstudio on linux.

    If for you it's a problem to enable plugin hot-plugging in the embedded version I have to go non-emebedded and force linux users to rebuild orx in order to use orxstudio.

    OrxStudio development continues, slowly, but continues.
    As of now we don't have a working version but while defining the features I ported the code of Ocean to the new project and added a few features the the base code.

    OrxStudio is made only of plugins iteracting each other.
    The basic plugin architecture is completed but we're still defining all plugin specializations.

    The main project data structure is defined and enables object templates, referencing and inheritance...just like as orx config system.
    I still have to make all entity to control the "native" entity exposed by NetOrx to make them visible in the orx window.

    The orx window is ready and it's an OrxStudio plugin based on NetOrx and Tao Framework to enable OpenGL usage from C#.

    As soon as we have a working code base we update the bitbucket repo to allow contributors (if any) to work on it.

    Anyone who wants to help is wellcome as we need plugin writers to extend features of the editor.

    If interested contact me on skype os by e-mail.

    Bye bye
  • edited November 2012
    ainvar wrote:
    I don't use the non-embedded version because I'd like to use the existing orx version the user has on it's pc.

    That's unsafe.
    It's unlikely that the version of orx a user has on his machine will be compatible with the one you're using in the editor.

    As for example, yesterday I removed a function from the orxDisplay API and added a new one (and updated all plugin implementations). A version mismatch with that one would crash or corrupt memory and wouldn't be very obvious to track as there's no versioning in orx itself.

    So I'm afraid you need to distribute a version of orx along your editor, and for now it's a bit less convenient as you'd need to provide both embedded and non-embedded till I get to support hotloading for embedded versions.

    Not sure which road you're taking for the editor GUI, but recently I've noticed the apparition of a couple of interesting game IDEs (both should be released soon) and thought you might find them interesting:

    - GDK:
    - Polyxode: http://polycode.tumblr.com/post/35658796259/heres-a-sneak-peek-at-what-the-polycode-2d-editor
  • edited November 2012
    You're right, it would be unsafe.

    I'll see what to do.
    For now I can continue using my orx.dll custom version but I'll come back to the problem when the core of OrxStudio will be ready for use.

    The GUI of the application is not yet defined in minimal details.
    I think we'll do something similar to the Ocean GUI that's it was something similar to the examples you linked.
    As of now it has docking supportand it's very flexible.
    I'm creating basic core views to edit parts of the software but it will be possible to "override" standard controls with other controls provided by plugins.
  • edited November 2012
    I decided to use the issue tracker more and more, so here's the item for supporting plugins hotloading in embedded mode: https://bitbucket.org/orx/orx/issue/12/support-plugin-hotloading-in-embedded-mode

    You can subscribe to it if you want to be notified of updates.
  • edited November 2012
    Thank you very much.
    I stand waiting for news :)

  • edited November 2012
    My pleasure!

    It's actually a much less trivial task than expected, mostly because plugins need to be unloaded first, freezing all dependent modules, new version loaded, module initialized and all dependent modules should then be updated.
    That's actually quite an heavy task and will probably take a while before being done! :/
  • edited April 2013
    *poke* *poke*

    Any news here? :)

    As you've seen, I wasn't able to do the hotloading in embedded mode as it's more complex than I first thought. Sorry about that!
  • edited April 2013
    Hi Iarwain,

    I'm sorry but I have no news about orx Studio.
    I had to halt development for a while because I'm out of free time.

    Sadly, since I'm still the only active coder of the project, the project itself is halted.

    I'm not giving up, I'm just waiting for this period to end and come back to Orx Studio and my game project too.

    Don't worry about hotloading, It's not a big problem and that's something I'll solve when it will be the time.

    If anybody is interested to join the development of Orx Studio is well accepted.

    May be the main need for the project is a C# coder that can write routines to handle orx api using NetOrx library.
    The architecture of the editor has become quite complex but is't plugin based so each developer has not to learn all architecture and can contribute quickly.

    As soon as I have news I write here.

    Bye bye
  • edited April 2013
    Hi ainvar,

    Nice to have some news of you! :)

    I'm sorry to hear that you didn't have more help with the editor so far.
    As for the lack of free time, I think it's something that affects us all at one point or the other, I hope you'll get more time to go back to your game project soon.

    Btw, if you're interested you can subscribe to the orx-dev google group.

    That's where we discuss of the new features to come or explain the recent changes.

    Thanks again for the update.

  • edited October 2013
    Hi people,

    after a long period I'm back on OrxStudio development.
    I still have not much time to dedicate to the project but for now I restarted developing few new things and reduced the amount of features I initially wanted.

    Few words on the future version:

    I completely removed Orx usage inside OrxStudio.
    The main reason is that the main goal of Orx is to be a game engine, not an editor canvas. That makes it a little hard to use inside an editor like the one I want to build.
    The second reason is that it wasn't 100% stable when thunked into a Winform application.

    So the current version of OrxStudio has a new Canvas based on bare OpenGL (OpenTK).

    The file format is xml and no more .ini. It will be possible to Export ini files and there will be a way to control how ini files will be generated in order to follow author preferences about folders, resources location and so on.

    The new version will provide a world editor, a body/body parts editor, graphics editor and animation editor.

    I don't know when I will be able to release something but as soon as I have something I will post it here.

Sign In or Register to comment.