Orx Studio

2»

Comments

  • edited September 2012
    @Grey: no propblem about sharing my code, but give me just a pair of days (may be just one) to complete the first part.

    I forgot to tell you all that there's a little disadvantage in using C# with orx.
    You have to recompile orx to make it to don't use fastcall calling convention (__orxFREEBASIC__ does it).
    As stated by Microsoft documentation for .NET 4.5 the FastCall calling convention is not supported.
    Some guys at Microsoft said that the benfit of the fastcall calling convention on modern machines is trascurable or, in some cases, it could slow the execution more than a cdecl or stdcall.

    @iarwain: I'm not a repository geek, and I don't know how to use git or mercurial or bitbucket.
    Since you gave me write permissions, I would use sourceforge if possible.
    May be I could create a folder in a branch...as soon as I decide the name of the library :)
  • edited September 2012
    ainvar wrote:
    Some guys at Microsoft said that the benfit of the fastcall calling convention on modern machines is trascurable or, in some cases, it could slow the execution more than a cdecl or stdcall.

    I'd be curious to see the source as I can't think of any way fastcall could be slower than stdcall (and even less than cdecl).
    As we speak of modern architectures, all the recent 64bit ABIs (windows64, system v amd64 / linux64, ...) have all removed the multiple calling convention standards and have opted for a unique one akin to fastcall.
    I'm not a repository geek, and I don't know how to use git or mercurial or bitbucket.
    Since you gave me write permissions, I would use sourceforge if possible.
    May be I could create a folder in a branch...as soon as I decide the name of the library :)

    Sure, but I was planning on putting the svn repository on read-only for history purposes and there's no more development happening there. Everything has been moved to http://code.orx-project.org.

    I'm using mercurial for orx/scroll myself but sausage is using git for his own projects, for example.
    It also makes work and sharing between multi-contributors much more easy and practical than svn did.
    If you're curious I'd recommend http://hginit.com for a smooth transition.
  • edited September 2012
    Hey Ainvar, happy to get even an incomplete copy honestly; I've a weekend ahead with only my tethered phone for internet (1.4kb/s MAX) so I'm more than happy to use my time to hack on orx + c# ;)

    By the way; I hope to use your work as a basis for making a 'wrapper' like Scroll. ie: not just a direct wrapper, but rather a 'tools and features' system on top of orx. Just in case you're curious why I am so interested. :D
  • edited September 2012
    iarwain wrote:
    ainvar wrote:
    Some guys at Microsoft said that the benfit of the fastcall calling convention on modern machines is trascurable or, in some cases, it could slow the execution more than a cdecl or stdcall.

    I'd be curious to see the source as I can't think of any way fastcall could be slower than stdcall (and even less than cdecl).
    As we speak of modern architectures, all the recent 64bit ABIs (windows64, system v amd64 / linux64, ...) have all removed the multiple calling convention standards and have opted for a unique one akin to fastcall.
    I'm not a repository geek, and I don't know how to use git or mercurial or bitbucket.
    Since you gave me write permissions, I would use sourceforge if possible.
    May be I could create a folder in a branch...as soon as I decide the name of the library :)

    Sure, but I was planning on putting the svn repository on read-only for history purposes and there's no more development happening there. Everything has been moved to http://code.orx-project.org.

    I'm using mercurial for orx/scroll myself but sausage is using git for his own projects, for example.
    It also makes work and sharing between multi-contributors much more easy and practical than svn did.
    If you're curious I'd recommend http://hginit.com for a smooth transition.
  • edited September 2012
    Grey, it seems we're on the same boat but with slightly different destinations :)

    Me too I was thinking about a scroll like library, but before all I'd like to:
    1 - import all orx functions
    2 - build classes as wrappers orx modules
    3 - build a scroll-like binding system

    Actually I'm near completion of point 1 and I've done a pair of classes of point 2 just for testing.

    We could join our forces to complete point 2 and 3 (and correct point 1 where needed) in order to haev a fully functional library.

    I need this library to have a full orx integration inside OrxStudio.
    Basic function import is good but a binding system is much more better.

    Cheers.
  • edited September 2012
    haha, looks like we're definitely headed in the same direction. I would be happy to collaborate on this, as I hope to use the library directly in game-dev, rather than indirectly (through Orx Studio) and the two uses seem like a good match to me.
  • edited September 2012
    ainvar: I believe you quoted me but didn't write any answer in your post. ;)
  • edited September 2012
    ok, that demostrates i'm not a forum geek too. :angry:

    I wanted to say that I don't remember where I read about fastcall but I remember the poster (it was on a forum) was a M$ Visual C++ Team guy.

    Anyway, the problem is still that .NET does not support fastcall on 32 bit :(



    And about hginit I wanted to say it's really well done, idiot proof...so with a some (huge) effort I could be able to understand some basics :)
    When it will be the time to release something I'll try to use it.

    Bye bye
  • edited September 2012
    ainvar wrote:
    And about hginit I wanted to say it's really well done, idiot proof...so with a some (huge) effort I could be able to understand some basics :)
    When it will be the time to release something I'll try to use it.

    Well, if you have any questions regarding hg or orx's repository, don't hesitate! :)
  • edited October 2012
    Hello everyone,

    a first version of the C# wrapper for orx is available.
    It's called NetOrx and you can find it here: https://bitbucket.org/orx/netorx

    To use it you must compile orx using __orxFREEBASIC__.
    We still have to solve a problem with delegate relocation so if you need to use callback, declare a static method and then use it in orx.

    Example:

    declare the static event handler:
    private static orxEVENT_HANDLER objEvtHandler = new orxEVENT_HANDLER(OnObjectEvent);

    Use it with orx:
    orxEvent.AddHandler(orxEVENT_TYPE.orxEVENT_TYPE_OBJECT, objEvtHandler);

    and implement the handler, of course:
    public static orxSTATUS OnObjectEvent(orxEVENT_Ptr _pstEvent)
    {
    return orxSTATUS.orxSTATUS_SUCCESS;
    }


    The code can't be considered as tested.
    We're going to clean it to make it more C#-ish and we need some users to use/test it.

    Ciao!
  • 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
    Hi,

    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:
    Hi,

    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:

    https://forum.orx-project.org/discussion/5107&limit=20&start=20#5167

    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.

    @iarwain:
    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.


    @community:
    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:
    @iarwain:
    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 :)

    Bye
  • 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.

    Cheers!
  • 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.

    Cheers.
Sign In or Register to comment.