Orx Studio

edited September 2012 in Projects - Tools
Hi folks,

as you can see on the Ocean thread, I asked to the community if it was possible to join our forces to create what could be considered one of the most (if not
THE most) wanted features : a sort of Orx IDE that allows fast game content editing.

Well...a pair of guys seems to be interested to this activity : Graag and enobayram.

I just terminated a pleasant skype conversation with that guys, and we talked about problems that we have to consider to build that new project.
For now we call it with an ambitious name : Orx Studio.

Here's a summary of our discussion:

The goal of Orx Studio should be to allow an easy and fast way to manage all game resources that orx engine can handle and create configuration files to use
in an orx based game.

To reach this goal we found we had common desires about features:

* Platforms : We would see Orx Studio running on Windows, Linux and MacOS. The intention is to maintain the same GUI across mentioned platfoms.

* Flexibility: We would allow community to write extensions to the Orx Studio.


As of now we are oriented to write the core of application in C++ because the major part of the Orx community should be familiar with it and because it's
possible to write cross-platform code.
For this purpose a partial rewrite of the Ocean project has to be done.

Since the core would be in C++, we thought it could be convenient way to have the GUI too in C++ and so we're trying to find the C++ cross-platform to use
for GUI and OS abstraction.
Qt seems to be a good candidate but if some of you have good advices we appreciate.

Since we would use Orx as the main render window, we're investigating about a possible integration of orx and Qt in the same way I've done with the first
version of Ocean.
That seems hard on Linux (X11) and MacOS (none of us knows how to do :) )


Actually we would to have an open architecture that's extensible. We are discussing between 2 ways to implement:

One could be to use sockets to exchange data between different applications.
In this case Orx Studio could expose the main data structure to the requesting application and accept the modified one to display.
That needs to have a socket protocol to communicate between Orx Studio and satellites.
That could allow every writer to have it's own development environment and use whatever tool he wants to develop extensions.

Another one could be using a dynamic plugin architecture. In this case plugins registers themselves and declare what they are meant for.
If they are activated, they would be called by Orx Studio when needed.
There could be file ex/im-porters, renderers, graphic editors, sound editors and so on.
That forces contributors to write in C/C++ (required to develop orx games) and use the Orx Studio Plugin interface.

We have pro and cons to both ways and we didn't reach a meeting point.


Now...here are things I'd like to be discussed on next skype meeting with them, and possibly other folks from the community
Since I'm the writer of the Ocean project, and since Orx Studio is in some way a collective extension to the original project, I'd like to discuss on my
original goals before inserting new features. (Just to understand how much I should rewrite :( )


Project files :
Ocean at the beginning was working with .ini files but the current (unreleased) version works with it's own binary format and exports ini files.
That allows storing IDE data without inserting unrelated infos into game ini files.
That allows, with a "loader" code, to use binary files instead of .ini while releasing the game, minimizing size too.
What do we want to do?


Editors:
Initially I had intention to add:
- Graphic object editor
- Animations editor
- Shader editor (as text editor)
- Physics editor
- Level editor
- Joint editor
- Text and Font editor

With editor I mean a special dialog (or set of windows) dedicated to configure a special section of the data structure.
We should better define how to implement editors and what we want from them.

Main View:
In the last (unreleased) Ocean version, I wanted to introduce new features:
- world editing : it would be used to edit contents of a game level.
- layout editor : was meant to edit the viewport layout as seen in the target screen. That means creating different preview for various resolutions (iphone, android devices, etc...)


Other features:
Last things I was thinking about Ocean were:
- Add special objects (Hero Spawning Points, Borders, Materials, Triggers and so on...)
- Draw path lines for walking characters



Ok, for now it's enough.
We've a lot to think about and to dream on.

We'd like to encourage the community to participate this project.

Here, we're all programmers...
Here, we all want to use orx...

It's not useful to have multiple unfinished projects.
We want to think that joining our forces we could make a complete one.

Stay tuned!
«1

Comments

  • edited September 2012
    Hi ainvar,

    Thank you very much for taking your time to write this. I'm in full support of this initiative, and looking forward to the process as well as the end result. I hope we have a very fruitful discussion with many people here and come up with an excellent basis to build on!
  • edited September 2012
    This thing is going to kick butt. If it gets made, I probably won't have a reason to use anything but Orx for my own personal projects. I love the community behind the engine as much as I love the engine itself. If I could help, let me know!
  • edited September 2012
    hi sonicbhoc,

    i added my skype contact on my profile so if you, or other people, want to talk about OrxStudio now you can reach me.

    Remember I live in Italy that's UTC+01.00 :)

    Bye bye
  • edited September 2012
    Hi!

    Very nice initiative! Maybe I could help, maybe not, depending of my free time, we will figure it out.

    Here, some questions and my opinion.
    The goal of Orx Studio should be to allow an easy and fast way to manage all game resources that orx engine can handle and create configuration files to use
    in an orx based game.

    Ok, here you mean Orx Studio will generate ini files, nothing more right ?

    Between socket/plugins, I really prefer the plugin approch. For the langage, I'm right for C++.

    But, maybe an idea: when I initialy read your post, my thinking was : "GUI ? Different view ? Cross Plateform ? Maybe, it can be an eclipse mod ?". I don't know how works eclipse internal, but I think there's a tons of good point in the eclipse SDK. In that case, langage will be Java for the editor. And the plugins system, the view, all the eclipse tools already exist ... But, this need a learning process (like learning QT ^^).
    Project files :
    Ocean at the beginning was working with .ini files but the current (unreleased) version works with it's own binary format and exports ini files.
    That allows storing IDE data without inserting unrelated infos into game ini files.

    I'm not sure to understand here. Initially, what was your ini files? Those used "in game" by orx ? All your projects files was ini files ? With some extra value never used in game ? I'm right or totally wrong ?

    In an other hand, working with binary file is possible, but when there's a bug in the serialization/deserialization, It can be very very difficult to find and to resolv the problem ... It can be necessary for "private data", but that's not the case here. Maybe a human understandable one is better.

    I think (but not sure, I'm just thinking right now) there will be 2 set of files generated by the IDE / Orx. One runtime and one for the rest. For the runtime, format will be ini files. For the rest, I don't know.
    That allows, with a "loader" code, to use binary files instead of .ini while releasing the game, minimizing size too.

    What is the task of this "loader" exactly? Not sure to understand. Orx Studio will generate ressources: ini files, and why not, bitmap, sound, etc.

    So, after that, like actually, to build/run your game, you will have to write your cpp/h files and implement your logic.

    Where this loader come into play ?
    Initially I had intention to add:
    - Graphic object editor
    - Animations editor
    - Shader editor (as text editor)
    - Physics editor
    - Level editor
    - Joint editor
    - Text and Font editor

    With editor I mean a special dialog (or set of windows) dedicated to configure a special section of the data structure.
    We should better define how to implement editors and what we want from them.

    Main View:
    In the last (unreleased) Ocean version, I wanted to introduce new features:
    - world editing : it would be used to edit contents of a game level.
    - layout editor : was meant to edit the viewport layout as seen in the target screen. That means creating different preview for various resolutions (iphone, android devices, etc...)

    Eclipse framework here ? ^^
    Other features:
    Last things I was thinking about Ocean were:
    - Add special objects (Hero Spawning Points, Borders, Materials, Triggers and so on...)
    - Draw path lines for walking characters

    Here, I have some questions. What's "draw path lines for walking characters" ? It's a line followed by an orxOBJECt in realtime ? So, ok to decide how to declare / store that in some ini files for orx. But, which code in runtime will handle that ? In that case, Orx Studio will provide a runtime library to handle that part in realtime ?

    Ok, stop here now, I'm hungry :p

    Hope my english is understandable ...
  • edited September 2012
    Huh...wow, it seems something cought your interest :)


    Here are answers to your questions. What I wrote in My Personal Idea paragraphs are my considerations that I have not discussed via skype.


    ---

    About the goal of Orx Studio, for now I can say we agree to generate .ini for game.

    My personal idea: It could generate more than simple .ini files and I think it should mantain a databse (PostgreSQL/SQLITE?) to store objects usable in other projects with an automatic import of resources and relative paths correction.

    ---

    About socket or plugins, we're still discussing.

    My personal idea: I'd go for plugin or better, for both ideas (it's possible to implement an RPC with TCP and call plugin system too :) ).

    ---

    We discussed about Eclipse during the first meeting.
    Well, none of us, for now, knows anything about customizing Eclipse.

    My personal idea:If you intend to create a full Eclipse environment where write the code and develop all the rest...well...I don't know where to start. Orx Studio is ambitious but I'd prefer a more simple solution that allows us to end the project.
    I think the simplest solution would be to write the GUI but before we have to define UI requirements.

    ---

    Ocean was intended to be able to work directly with .ini files used by the game. The project folder of Ocean was the 'root' of the game folder.
    You're right, there were extra values into ini file that were not used in game.

    My personal idea: I think it's better to have a binary format for Orx Studio and release C/C++ source code to let the game load binaries directly as an alternative to ini files.
    That's the loader I was talking about...a little library to use in the game (like scroll) used to do orxStudioLib_LoadBinaryConfig("filename.bin") and get orx structure filled with what we would find in a traditional ini.
    It's a plus, in fact we MUST have OrxStudio exporters for ini files in order to generate clean ini files for the game of who wants to use orx with them.

    ---

    About editors. Not yet discussed.

    My personal loooong idea:

    If you create a dialog for Eclipse :
    .you have to study Eclipse functioning
    .you have to draw and handle dialog + Eclipse stuff
    .you have to manage your own data set


    To create the same dialog you would create in your own editor.
    .you have to draw and handle dialog
    .you have to manage your own data set

    I don't see the added value of using Eclipse for few parameter dialogs.
    For graphic editor we basically need to locate the image and specify the portion to use (already done in Ocean)
    For the animation editor we need an evolution of the Graphic editor that allows us to create lists of animations and preview them (just to say)
    Shader editor needs a test editor...but who writes shaders may be that wants to use nvidia editors or other stuff.
    The Level editor is the current main view of Ocean.
    At this point Id like to add an Object editor that can edit animation, physics and joints.
    Text and fonts editor would be a big list of sentences and font preview to generate.

    I made things more simple that what they could be, but it's just to say that all editors must be done if you use Eclipse or if you don't.

    When I changed the UI of Ocean, it took me few hours respect to the job I had to do to it's internal architecture.
    The main effort was to make the orx windows to work as expected.
    In the last Ocean version, it took more time to write a renderer windows (because I had substituted orx) than the rest.
    I don't see the UI itself a big problem.

    If we move to Eclipse we have to use Java too.
    I think who uses orx basically knows C/C++ and if we want community to partecipate we should give a friendly environment.

    ---

    When I was thinking about walking paths I was thinking about savind plain text files with informations needed by the game to reconstruct the path at runtime.
    And yes, I was thinking to let the game to load those files using the loader i mentioned before

    ---

    Sorry for being so negative on Eclipse.
    Let's take apart the effort to write JNI interface if we want to use native library (i've done it to use orx directly from c#...i'll never do it another time : ).
    It's true I hate it as IDE, but I tried to understand if it could save time (in the long run) to our project...to me it seems to screw with a hammer...it's not the right tool.

    That said, I'd be happy if someone can show me I'm wrong :)

    Bye bye
  • edited September 2012
    Ok about eclipse ;)

    You're right, in all case, you'll have to write all editors, but I'm sure that eclipse give you a lot of usefull functionnality to make an editor like that.

    But, it just was an idea ^^ I don't really like eclipse too :)

    Eclipse is not a GUI library, it's more than that (I think). QT is a GUI library. It's not the same. Eclipse already define what's an editor, communication between them, an outline, all of that.

    The main problem of eclipse is the JNI call to call orx, it's sure.

    I repeat, it was just an idea, QT is fine for me too :)

    --

    About the binary format, you talk about orxStudioLib_LoadBinaryConfig("filename.bin"). You will use this call to load your scene, to create and initialize your objects yourself. Why ? What's orxXXX_LoadFromConfig() are doing wrong ? Or maybe what's missing ?

    If the question is about filesize, you can compress ini file in orx (never tested).

    I'm not sure to understand the add for this function ;)

    And when a new property will be available in orx, you will have to add a serialisation/deserialisation for that in your loader + the code to init orx from the property (and the edition of that property, but this part is normal :)).

    Where I am wrong or missed something ? :)

    --

    For the walking character and path, if it's a runtime functionnality, instead of adding a new layer on top of orx, maybe it will be better to add that in orx itself ?

    --

    I don't want to be negative too, I just want this tool the best possible, so I just want to participate a little ;)

    Good night all ! ;)
  • edited September 2012
    You're right about extended functionalities you can gain using eclipse.
    To me the main (and only) good point of eclipse is that it has the plugin system done.
    But it comes at the cost of Java, JNI, learning curve and so on.

    If I have to choose between C# and Java in Eclipse I would choose C# due to delegates (Ocean lives with delegates) and properties. They both have reflection that makes plugin writing like a joke.
    But that's my personal preference.

    For GUI framework...tonight I was evaluating wxWidgets vs Qt. Both does the job.
    If I have to express a preference I'd go for wxWidgets because it's made in full C++ and it doesn't need MOC.
    But I have to dig more deeply to better understand both.

    In any case, it's not tree, buttons and list that I'm worried about.
    I think main UI problem is the orx control that must handle OpenGL.
    To make orx to work in a client window/widget there will be need to modify GLFW for all platforms, in order to used a given and a given target window/widget with a ready opengl context.

    About the orxStudioLib_LoadBinaryConfig...it was an example that come from my mind.
    If it's possible to compress and encrypt configuration files may be my orxStudioLib_XXX it's a bu##sh*t :)

    For waking paths...yes, we could think about adding it to the runtime, like other special objects.

    Don't worry about being negative. I like that you ask a lot of detailed questions but the main problem now it's that I don't have answers because we're in a brainstorming phase. :)

    I would concentrate more on the global view, if we want or not a feature or not...not how to implement it.
    Once we know what we want, we can design the architecture that permits all requirements and it's extensions.

    Few minutes ago I took a look at all sources of Ocean to see what would mean to convert it in C++...and I started crying :(

    bye bye
  • edited September 2012
    I would avoid eclipse. And I'm honestly a little biased towards QT because I'm a KDE user. :P

    Good luck planning this thing! I can't wait to use it, or help build it if there's something I can do. (I'd love to do some bug testing though, definitely.)
  • edited September 2012
    Yesterday we discussed a bit about Qt, Eclipse and other points.

    Actually we are thinking to 2 kinds of solutions.

    -= Solution 1 =-

    A cross-platform C++ GUI framework + a C++ core system + plugins

    This allows us to write the software entirely in C++ and that means:
    - with a clean and easy plugin interface, every user of orx could be a potential contributor.
    - no need to interface orx library with exotic wrappers/interfaces for Java, C#, Whatever.


    -= Solution 2 -

    Eclipse modding

    This mean that who wants to partecipate must know Java, understand Eclipse intimate secrets to create addons but Eclipse offers nice features like a working plugin system, project management, autoupdates, etc..
    It means too we have to create an interface for orx and discover if there's a way to make orx to work in a Java widget and if there's a cross-platform solution for that (probably yes).


    Since the major part of the job would be to write editors for various objects used in orx, animation editor, physic editor, and handling of orx widget, may be it doesn't worth to increase complexity using Eclipse and forcing developers to use a less common language (I mean in an orx community i think people would use c or c++ to develop games rather than Java).
    That's why we are leaning towards solution 1.

    We'd like to have your comments about that.


    For now we would better investigate Solution 1 bacause we have no notion about Solution 2 (until someone enlight us :) )


    We need a cross-platform C++ GUI framework that allow us to have:
    - standard controls (button, checkbox, radiobutton, combo, list, tree, view, panels, etc)

    - an easy way to override standard controls behaviour withour rewriting the control

    - the opportunity to create opengl contexts

    - a stable wysiwyg editor.


    We are thinking to go for Qt but since none of us used it extensively, we'd like to know experience of other users.

    From my point of view, except the fact that we've to add MOC stuff to the build flow, I don't see negative points in using it.

    I used wxWidgets (when it's name was wxWindows) and it was not bad, but I was an MFC developer so for me was easy :)
    To me it could be a valid alternative because it's quite mature, and gets the job done.
    It does not add steps to a build flow and it's less bloated than other libraries.
    It can use native widgets of the platfor where the application is running, instead of simulating them.

    I also used Gtk years ago.
    It works like other GUI libraries, it does not add complexity to the build system but...it draws gtk widgets without using the native ones and it has a C interface (gtkmm could be an alternative).


    What do you guy think about using Qt?
    Any disadvantages?
    Are there any alternative?
    What advantages do the alternative have over Qt?


    Bye bye
  • edited September 2012
    Hi ainvar,

    Thanks again for summarizing our long discussion. I'd like to add a minor point. Even though at first sight, it looks like we need just the basic widgets, I think they're actually the absolute minimum we need. When we start building something complex, we're sure to realize the need for more advanced features, such as a nice drag and drop support (across processes), advanced widgets: displaying html documents, a comprehensive drawing support for our custom widgets, and many more I can't foresee right now. That's why we should assign some extra positive points for more advanced toolkits, under the heading "Unforeseen long-term requirements".

    That actually goes for Eclipse as well, the platform probably provides many features for free, that we don't even know we'll need yet.

    I'd also like to mention another advantage of using Java (this probably goes for C# too). One thing I really like about a java tool, is the ability to provide a simple .jar file that your users can run, regardless of their operating system. Similarly, the source code is also much more portable, out of the box.

    Now, you could say that we'll need to interface Orx, so we'll have native dependencies anyway. I think this is actually less of a problem than it appears:
    - We have two dependencies: orx.dll and orxinterface.dll (that we create)
    - orx.dll (or any other operating system variant) logically needs to be already available in the users computer, compiled for her/his platform, since s/he is an orx user.
    - orx is C based (thumbs up iarwain :) ), as will its wrapper be
    - orxinterface.dll is a very thin wrapper around orx.dll, and it's the only dependency for it. So, once we compile the interface for a given operating system, we could bundle the binary with the .jar, and it would work as long as it finds an orx.dll

    In conclusion: if we use Java/C#/Python etc. it might actually be possible to distribute the orx studio in binary form in a cross-platform manner. This also simplifies the distribution of source code greatly.

    Sorry for introducing yet another point to consider :P
    Cheers!
  • edited September 2012
    Hi enis,

    no problem.

    Your point of view sounds good.

    - We have a large code base (Ocean) in C#
    - To use C# with native environments we have less things to do than Java.
    - With mono we're cross plarform.
    - .net framework is as complete as the Java one.
    - Java and C# are more proficient languages (90% of times)
    - we have a GUI framework.

    So I ask you..why don't we keep going on with Ocean code?
    We we should restart in other languages?

    See you later on skype ;)

    Bye
  • edited September 2012
    Thumbs up for all of you guys.

    ainvar wrote:
    So I ask you..why don't we keep going on with Ocean code?
    We we should restart in other languages?

    You said you changed the renderer for the last version of Ocean, from orx to something else, right?

    Does orx render the scene created by Ocean in the exact same way? Wysiwyg?

    If so, I don't see any reason to drop ocean code base.
  • edited September 2012
    I've been wanting to reply here for the last few days but I'm not fast enough to keep with the latest evolution of the thread.

    So here are a couple of random thoughts/reactions, hope you'll forgive me:

    It's an awesome idea! Community-driven editor sounds great, made by the community, for the community. I believe no one can make a better tool than the people that are going to use it.
    When orx started (and didn't have any name), an editor was supposed to be developed at the same time. As you might have noticed that never happened. Later on, in ~2006 I think, faistoiplaisir began to have a look at Eclipse and see if he could contribute there to help with the idea of having an editor for orx. But that was much before he actually became an orx user so that never happened either. ;)

    I like the plugin approach but I think it doesn't have to be exclusive with a network protocol. Plugin is nice for direct integration and basic communication (init, exit, run, ...) and an actual network protocol allows for a much less restrictive communication, including extension to in-game itself, like debugging (remote connection, remote console, etc...). Anyway, your call! :)

    I don't want to interfere with that project at all, all the choices are to be made by the community, for the community, but I'll be happy to help with any questions/requests about orx's internals.

    Disclaimer: as a user, I dislike most contemporary UIs and as such I'm probably not the target audience.

    However I like the idea of being able to run the editor on the most platform possibles. Which also mean I like acksys' current approach of adding a UI layer with an orx-based application.
    Orx already runs on a fair number of platforms, can render directly your game without any hack for low level library modifications (WYSIWYG), and UIs can be themable depending on what's used (did I already said I really dislike contemporary UIs that feel both dry and cold to me? ;)).

    That's all folks! :)
  • edited September 2012
    Hi iarwain,
    Later on, in ~2006 I think, faistoiplaisir began to have a look at Eclipse

    I've also argued a bit for an eclipse-based editor, but it has 2 drawbacks: Even though it's not unseen to have graphical editors in Eclipse, it's primarily a programming IDE, and its general ambiance reflects that. The second one is the fact that, in order to use an eclipse-based editor, you'd have to install eclipse first. Even though you don't have to use Eclipse for anything else, the users will still feel like they're using Eclipse. This might be a barrier to entry.

    Maybe there's also a third important argument, but that's about Java in general: In order to embed an orx widget inside java, we have to create and compile a JNI interface for orx. That means, Linux users will have to compile something before using the editor. Aside from that, this requirement somehow complicates the build system and source distribution etc.

    Being a Linux lover and a Microsoft hater, surprisingly I am convinced to use C#, based on its merits for this project. We're discussing ways to eliminate any native compilation, so that a user can simply copy his/her orx.dll (liborx.so etc.) into a certain folder, and the cross-platform orx studio .NET binaries would work out of the box. This seems to be possible with C#, since it can call native functions from a dynamic library without the need for an interface.

    C# also comes with the huge benefit of being able to use ainvar's existing efforts into the subject.
    However I like the idea of being able to run the editor on the most platform possibles.

    For a while, I was also excited by the possibility to run the editor on a tablet, but it's a gimmick really... It's hard to justify its existence against any significant development overhead... Linux, Windows and Mac are definitely "must support" , but anything more is really hard to justify.
    did I already said I really dislike contemporary UIs that feel both dry and cold to me?

    Well, I personally like whatever gets the job done in the most efficient way. Contemporary UI toolkits are waaay more than just buttons and windows... Besides, while making that comment maybe you weren't considering the fact that we're fully committed to have an orx widget in the editor.
  • edited September 2012
    iarwain, I think the point is not if we like or not an UI. The point is that's better to have an ugly but useful editor than to have no editor at all :)

    Acksys is doing a nice job with integrating a gui system into orx, but I think that will work well on games rather than a complex GUI system.
    Or better...it can work, but it's a young project and needs more time/resources to become stable.
    And to build OrxStudio we need a designer...that can't be OrxStudio itself :)

    Anyway, yesterday we've talked a bit and we're near to define main points.
    Now we agree it's better to restart from Ocean code base.

    I'm going to modify and clean the current architecture to include a plugin system.

    We'd need a pair of modifications, to actual orx version, to make all things to work.
    When I started Ocean I've done a modification to orx to allow it to be used in a child window context.
    Now, we need this modification to improve and to work on win32, linux and mac os.

    I wanted to write a mail to iarwain but I guess if he used glfw it's because he did not want to write all platform specific stuff.

    So I ask you all to help me:
    If I'm not wrong, GLFW it's used on win, linux and mac versions of orx.
    Orx creates the main window by calling GLFW.
    GLFW uses the proper create method depending on the platform it has been compiler for.
    On windows it uses winapi.
    On linux it uses X11.
    On mac it uses cocoa.

    GLFW internally uses a _GLFWwndconfig structure to store infos about created window.

    I'd like to add 2 integers to that structure. The first is "parent_handle" and the second is "handle_in_use".

    "parent_handle" will be (uint)-1 (by default) or a valid positive number. It will store the handle of the window that will contain our orx window.

    "handle_in_use" will have same range of values, but indicates that we already created the window and we want orx to use it (and to create the opengl context).

    If "handle_in_use" has a value different by -1, the value of "parent_handle" will be not taken in account.

    I know how to make this modification in windows but I don't know how to make it in linux and mac.
    I'll try soon to make this mod on linux, but I see it really hard on Mac.
    Is there anyone willing to try?

    The second modification has to do with orx itsef.
    It could accept more parameters on the init functions, or read parameters directly from ini files.
    There's need of a mechanism to allow "parent_handle" and "handle_in_use" to be given to glfw.
    I would not modify anything that has to do with orxDisplay, except adding a pair of members to a structure that only glfw plugin will use.


    The problem I still have to solve, in the low level, is how to integrate mono to the x11 and cocoa environment in order to give orx valid native window handlers.
    Once done that we'll be able to correctly run orx with any java/c#/whatever application as a child window.

    Do you have any other idea on how to achieve the same result?
  • edited September 2012
    Peso wrote:
    Thumbs up for all of you guys.

    ainvar wrote:
    So I ask you..why don't we keep going on with Ocean code?
    We we should restart in other languages?

    You said you changed the renderer for the last version of Ocean, from orx to something else, right?

    Does orx render the scene created by Ocean in the exact same way? Wysiwyg?

    If so, I don't see any reason to drop ocean code base.

    Yes I changed the renderer for the last version but it's not complete and it does not render the scene as orx. It's a close limited emulation but a lot more easy to use. More than a wysiwyg it's a awysiqstwycg.

    almost
    what
    you
    see
    is
    quite
    similar
    to
    what
    you
    could
    get

    :)
  • edited September 2012
    ainvar wrote:
    Yes I changed the renderer for the last version but it's not complete and it does not render the scene as orx. It's a close limited emulation but a lot more easy to use. More than a wysiwyg it's a awysiqstwycg.

    I think we should keep and maintain this renderer. It would be a nice fall back strategy. Both during development, before the orxWidget and its controller is ready, and for release, for a user that doesn't have the compiled orx binaries. I'm not saying it should emulate orx entirely, but a lot of basic rendering can be done with minimal effort.
  • edited September 2012
    I've done a new architecture draft...once more complete i'll publish.

    Meanwhile i'd say that the renderer will be a plugin too so there will be no problem about switching the type of renderer.
    We can use the ugly one i made while we wait to complete the ora one...so we can postpone needed orx modifications and go on.
    We can do another thing too...we could "port" a part of orx code to let the c# render to behave the same as orx (for plain bitmap rendering).
  • edited September 2012
    enobayram wrote:
    Hi iarwain,

    Hi enobayram!
    I've also argued a bit for an eclipse-based editor, but it has 2 drawbacks: Even though it's not unseen to have graphical editors in Eclipse, it's primarily a programming IDE, and its general ambiance reflects that. The second one is the fact that, in order to use an eclipse-based editor, you'd have to install eclipse first. Even though you don't have to use Eclipse for anything else, the users will still feel like they're using Eclipse. This might be a barrier to entry.

    Maybe there's also a third important argument, but that's about Java in general: In order to embed an orx widget inside java, we have to create and compile a JNI interface for orx. That means, Linux users will have to compile something before using the editor. Aside from that, this requirement somehow complicates the build system and source distribution etc.

    Being a Linux lover and a Microsoft hater, surprisingly I am convinced to use C#, based on its merits for this project. We're discussing ways to eliminate any native compilation, so that a user can simply copy his/her orx.dll (liborx.so etc.) into a certain folder, and the cross-platform orx studio .NET binaries would work out of the box. This seems to be possible with C#, since it can call native functions from a dynamic library without the need for an interface.

    C# also comes with the huge benefit of being able to use ainvar's existing efforts into the subject.

    I was simply mentioning history. :) As I said I do not wish to interfere in choices made by the community as it's a tool made by the community for the community. Not something I'll be involved neither on the coder side and nor on the user side.
    For a while, I was also excited by the possibility to run the editor on a tablet, but it's a gimmick really... It's hard to justify its existence against any significant development overhead... Linux, Windows and Mac are definitely "must support" , but anything more is really hard to justify.

    Well it's gimmick, yes and no. If you have an editor and you supply a bank of resources and behavior or a visual way of editing timelines, you can then develop simple games/prototypes directly on iPad. It already has been done and there's an audience for this.
    But I was more thinking of platforms such as Raspberry Pi or any OS that would potentially be supported down the line at some point (ReactOS, QNX, AmigaOS, etc...).
    Well, I personally like whatever gets the job done in the most efficient way. Contemporary UI toolkits are waaay more than just buttons and windows... Besides, while making that comment maybe you weren't considering the fact that we're fully committed to have an orx widget in the editor.

    Well that's my point, contemporary UIs don't get the job done for me. They are terrible from an ergonomic point of view or for readability, that's why I'll probably stick with simple text edition for most of the tasks.
    As for the orx widget I thought it was supposed to be contained within the editor, like a render slave of some sort, not to actually be doing any edition work but I probably got that part wrong. :)

    And again, I'm not the target audience so don't pay attention to my ramblings. :)
  • edited September 2012
    ainvar wrote:
    iarwain, I think the point is not if we like or not an UI. The point is that's better to have an ugly but useful editor than to have no editor at all :)

    Well to each his own, I guess. I'm very happy with this community editor project and I repeat it here again, I'm not the target audience so don't mind me. However, from a strictly personal point of view, I'd rather stick with text edition than any visual editor if it doesn't feel natural to use to me.
    Acksys is doing a nice job with integrating a gui system into orx, but I think that will work well on games rather than a complex GUI system.

    Mmh, maybe. But it might depend on what we call a complex GUI system. I think there are many ways to make very practical UIs with very simple controls and any complex control usually misses the point for me.
    Or better...it can work, but it's a young project and needs more time/resources to become stable.
    And to build OrxStudio we need a designer...that can't be OrxStudio itself :)

    I'll choose the chicken over the egg! ;)
    Anyway, yesterday we've talked a bit and we're near to define main points.
    Now we agree it's better to restart from Ocean code base.

    I can grant you write access to http://bitbucket.org/orx if you're interested, as well as some space on orx's server.
    Do you have any other idea on how to achieve the same result?

    Nope, sorry!

    Anyway, I don't mean to pollute this thread so I'll go back to passively keep updated and watch your progress.

    I'm very thrilled that it's not a one-man project and I'm looking forward to seeing where it goes. Best of luck and if you have any questions, you know where to find me! ;)
  • edited September 2012
    I have a quick question;

    In order to implement the orx widget, what would you think about running orx in the background, letting it render a viewport into a texture and drawing that texture to an OpenGL widget (or even non-OpenGL possibly) in the GUI?

    If we were to do this, is there a way to hide the orx window? Will the texture rendering take place if the actual orx window is minimized/hidden/somehow closed?
  • edited September 2012
    I believe that's a solution that was proposed in the Ocean thread back then, or at least in discussions we had offline with ainvar.

    Unfortunately, the OpenGL context comes with a window when using GLFW. They're tied together and you can't have one without the other, so the best you can do there is have the windows minimized, but in that case the rendering phase is skipped by default (but that should be easy to work around).

    Now if the editor were to use orx with a different display plugin, either OpenGL-based or not, this technique should work just fine.
    It can be done for many render targets as well that could be displayed separately in the editor if needed (like animation cycles within the animation graph display, for example).
  • edited September 2012
    iarwain wrote:
    I believe that's a solution that was proposed in the Ocean thread back then, or at least in discussions we had offline with ainvar.

    No, this one is a different solution.

    What I've done in Ocean was similar to what I told you offline, but Enis is asking you if it's possible to hide orx window and use orx to render to a texture that we can use for our purposes.

    iarwain, as I said in my mail, I wanted to add a parallel behaviour to the GLFW plugin in order to make plugin entry points calls to be redirected to our C# environment

    You asked why we should do that and not to create another plugin.
    Well, the answer is that we'd like to avoid to recompile a special orx version to use with orxstudio.
    It would be nice to have orxstudio to work with the standard orx libray.

    Yesterday me and Enis talked a bit and found what could be a better way to include the modification.
    In the display GLFW plugin there are only 35 calls to glfw itself.
    We could just reimplement in C# side the used glfw functions and decide with implementstion to call at runtime.

    something like:

    if (use_callback) {
    call_back();
    } else {
    glfw_oroginal_function();
    }

    placed in 35 points.

    That could permit to use a standard precompiled orx library and we could release binaries instead of sources to recompile (sources will be still available)

    But since this modification should be done for display, mouse, joy, keyb...may be iarwain is right when saying "why don't you write your own plugin?"

    Cheers
  • edited September 2012
    ainvar wrote:
    iarwain wrote:
    I believe that's a solution that was proposed in the Ocean thread back then, or at least in discussions we had offline with ainvar.

    No, this one is a different solution.

    What I've done in Ocean was similar to what I told you offline, but Enis is asking you if it's possible to hide orx window and use orx to render to a texture that we can use for our purposes.

    That's what I meant. I was not speaking of your final decision for Ocean, I was referring to that post where I suggested to do offline rendering to texture and then use those for your own display needs.
    Well, the answer is that we'd like to avoid to recompile a special orx version to use with orxstudio.
    It would be nice to have orxstudio to work with the standard orx libray.

    And that would be the case. The option I'm suggesting doesn't require any change to orx or its current plugins at all. Simply have your editor come with a set of dedicated plugins and then hotload them after orx is started using the orxPlugin API. It's the least intrusive solution, I believe, and keeps any editor-specific code outside of orx.
    Yesterday me and Enis talked a bit and found what could be a better way to include the modification.
    In the display GLFW plugin there are only 35 calls to glfw itself.
    We could just reimplement in C# side the used glfw functions and decide with implementstion to call at runtime.

    something like:

    if (use_callback) {
    call_back();
    } else {
    glfw_oroginal_function();
    }

    placed in 35 points.

    That could permit to use a standard precompiled orx library and we could release binaries instead of sources to recompile (sources will be still available)

    But since this modification should be done for display, mouse, joy, keyb...may be iarwain is right when saying "why don't you write your own plugin?"

    This solution is somewhat intrusive and doesn't serve a global purpose, only the editor. That also means that when the plugin code change I have to maintain those hooks for the editor or create new ones if needed.
    This doesn't sound very practical nor clean to me, to be honest.

    Cheers!
  • edited September 2012
    Hi iarwain,

    the hot plugin load seems really interesting! I really like it!
    But I don't see how to implement it.

    We want the new plugins being loaded before orx opens the window.

    In orx_execute we specify _pfnInit but the function is called after the display plugin is initialized.
    It can't work.

    The "plugin" key in [Param] section seems to be taken in account by orxPlugin_ProcessParams only if orx is not compiled as embedded.
    We want the plugin to be active for embedded compilation too.

    I guess we can use directly orxPlugin_LoadUsingExt but code of the 'game' is called after the display plugin has been initialized.

    Do you this it's possible to load our plugins before orx opens the window?


    Cheers

    EDIT

    I was jocked by orx.ini in the demo.

    [Param]
    plugin = plugins/orxDisplay_SFML plugins/orxPhysics_Box2D plugins/orxMouse_SFML plugins/orxKeyboard_SFML plugins/orxJoystick_SFML plugins/orxSoundSystem_SFML plugins/orxRender_Home

    I compiled in embedded dynamic debug.
    I am missing something...Where are those plugin located?
  • edited September 2012
    Hey ainvar,

    So yes, I'll probably have to make sure hotloading still work (haven't used it for years!) and then allow it to work for embedded builds too.
    That shouldn't be too bad. :)

    Is that something you need very soon or can it wait a bit?
  • edited September 2012
    well, it depends what you mean with "soon" :)

    We're still defining all editor architecture and features so it will take some day.
    We don't need it made asap, I think we can wait one or two weeks.

    But I'd like to understand how it should be intended to work because i see the orx.ini file in the demo it's loading plugins using [Param].

    Can you see the ---EDIT--- of my previous post?


    Cheers
  • edited September 2012
    Yep, I don't get notifications for edits but when explicitly mentioned it's fine! :)

    The orx.ini is supposed to work with both embedded and non-embedded demos, hence the Param.plugin key which is ignored in embedded mode as the plugin module doesn't process its command line parameter.

    I have quite a few things going on for the next month or so, but I should be able to work on that mid-october if that's not too late for you.

    The way it works is that you have 3 options:
    - you can specify the plugins in config and orx will use the new ones instead of the embedded ones (not yet supported)
    - you can specify the plugins on the command line sent to orx, same execution way as above
    - you can manually hotload the plugins after orx is initialized, which means you get a screen creation for a split second before the new plugins are getting used in embedded mode (not sure if that's supported either) or you don't get anything till you hotload the plugins in non-embedded mode (should be already supported)
  • edited September 2012
    Your solutions #1 and #2 are nice. How should the plugin registration work?

    For now i could modify my local copy of GLFW plugins to make them to work as expected for out purposes and when your modifications will be ready i'll use one of the new features.

    I guess the cleanest method could be to use the config files and the command line.
    The third method is a plus, but in the case of glfw plugins is not really clean because you start with one plugin then you have to swap at runtime...i don't knew, it could be useful for other kind of plugins but i don't see a practical example except experimental exitic orx usage :)

    thank you iarwain, as alway you gave me the best and cleanest solution.

    I know you're not interested but one of the collateral effects of all this (new Plugins + Ocean/OrxStudio) is that the community will have a full operational .NET wrapper library for orx that could be integrated everywhere, even on Windows Phone.
    This would allow not only fast game prototyping but super-fast game prototyping.
    It could allow ports of c# games that currently use xna to android and iphone platforms using mono for android and mono touch.
    It will be possible to make the same for Java games (oh oh oh...except iPhone :) )

    To me, the most important missing part of the orx system, is the fact it can't be run in multiple instances...but that would mean to add a handle param to each function, to add an instance manager and so on.
    That could expand a lot the usage of orx engine because it could become a wiget used not only for games.

    I don't expect a serious comment on the last two things, it's just propaganda to stimulate someone to join our project :)

    Cheers
  • edited September 2012
    I forgot one thing.

    Your solution can't work, in our case, if we don't find a clean way to make possible to send parameters from the application to the plugin.
    In our specific case we need to send a structure filled with pointers to callbacks to call.

    I could pre-load a dll that exports an API used to store those pointers in a static data, then dynamically load the same dll from the plugin and I should find the same values.

    Can someone confirm this technique works on linux and mac too?

    Do you see a better way?

    Cheers
  • edited September 2012
    The callbacks could be function pointers in the global scope. We could load orx with our plugin and then set those function pointers to our C# callbacks. Wouldn't that work?
  • edited September 2012
    I've done it.
    Just rewrote a fake GLFW that exports a function.
    orx.dll exports my function and i've just to map it into c# :)

    Now the hard work begins...i've to implement in c# all the glfw functions that were called by orx.

    --- edit ---

    Enis, to answer you, i've what you wrote, just organized the callbacks into a structure so c# sends the structure filled with right pointers, and the plugin does a memcpy to it's own copy.





    Cheers
  • edited September 2012
    Good news.

    I can receive all callbacks from the C# side. Now all I have to do is to re-implement the OpenGL window in C#, and all tha black magic stuff the GLFW was doing for window handling and managing.

    The cooking recipe wanted:
    - 500 gr of fake GLFW plugin with a new exported (__dllexport) API used to save a structure full of functions pointer to call back when orx calls needed GLFE functions.

    - 20 gr of C++ native library to implement nasty orx starter (needed because I could not rewrite orx_execute in c# due to _orxDebug_init and other stuff.

    - 1500 gr of prepared orx imports for C#

    - 300 gr of prepared orx interface library imports for C#

    Take all an mix for 5 developing hours, then place fresh on the plate and have fun preparing the sausage.

    Cheers
  • edited September 2012
    Hi ainvar,

    I'm watching your progress with excitement, and looking forward to tasting what you're baking for us!

    Meanwhile, I've made a strange observation: (at least in linux)

    When you statically link some functions into an executable, it's not possible to redirect these functions using LD_PRELOAD. This, I guess, would be expected by anyone familiar with what I'm talking about. But my strange observation happens when you try to statically link a function in a shared object, and then later LD_PRELOAD that function. Magically, even though the shared object has been compiled to link it statically, the functions in the pre-loaded shared objects replace the original ones!

    To be explicit, here's what I've tried:
    $>cat loop.c
    
    void f(){}
    
    void doit() {
    	while(1) {
    		f();
    	}
    }
    
    $>cat executable.c
    void doit();
    
    int main() {
           doit();
    }
    
    $> cat inject.c
    #include<stdio.h>
    #include<stdlib.h>
    void f() {
    	printf("I'm freee!
    ");
    	exit(0);
    }
    
    $> gcc loop.c -fPIC -shared -o libloop.so -O3
    $> gcc executable.c -lloop -L. -O3 -oexecutable
    $> gcc inject.c -fPIC -shared -o libinject.so
    
    $> LD_LIBRARY_PATH=. ./executable
     [loops forever]
    
    $> LD_PRELOAD=libinject.so LD_LIBRARY_PATH=. ./executable
    I'm freee!
    $>
    

    Now, is it just me, or does that mean that we can inject our glfw fake implementations simply through an LD_PRELOAD (and hopefully windows and mac equivalents)?
  • edited September 2012
    I've just tried this, it works!!! Can anybody try and see if this also works with other platforms:
    $>pwd
    /home/enis/local/orx/tutorial/bin/linux64
    
    $>cat fakeGLFW.c
    #include<stdio.h>
    int glfwInit() {printf("none
    
    calling me!
    
    ");}
    
    $> gcc fakeGLFW.c -fPIC -shared -o libfake.so
    $> LD_PRELOAD=libfake.so LD_LIBRARY_PATH=. ./01_Object.sh
    
    
    calling me!
    ...
    
  • edited September 2012
    Wow you guys are fast O_o.

    Writing a fake GLFW seemed to me as the best way from the start. I did not consider it could be done in C# and dynamically loaded at run time. Simply amazing :woohoo: .

    Out of curiosity what are you planning to use to implement an opengl control in C#?

    Cheers,
    Graag
  • edited September 2012
    The injection via LD_PRELOAD is a good idea but I don't know of any windows equivalent.
  • edited September 2012
    Yep, but in those cases you need a separate DLL anyway, so why not load it as a plugin the way it was meant to be?
  • edited September 2012
    Because arbitrary complexity is awesome? ;)

    Edit: by the way, awesome project guys, Looking forward to seeing what comes out of it. (c# bindings *drool*)
  • edited September 2012
    iarwain wrote:
    Yep, but in those cases you need a separate DLL anyway, so why not load it as a plugin the way it was meant to be?

    On Windows, the problem isn't that bad anyway. We can distribute the orx.dll modified to accommodate the editor. Likewise in Mac OS. In Linux, however, we have to force the user to build from source. That in theory, means that we need to distribute the orx source entirely, the version that is known to build with our plugin. With the LD_PRELOAD approach, we will need to either:
    - Distribute no native binaries at all (if C# can inject its callbacks as symbols)
    - Distribute a libFakeGLFW.so to be preloaded. This is possible, because a dummy shared library will only depend on glibc and other very fundamental stuff that is probably the same on all linux systems.
    - Distribute a very simple source code to compile libFakeGLFW.so, but it will be VERY simple to generate it since it has no dependencies. Just a .c file to compile (We'll probably do that before starting the studio for the first time.)

    All of this really simplifies our source tree and the build process. It's also much more future-proof on all platforms.
  • edited September 2012
    @graag: I'm going to use the Tao library that is an importer of OpenGL functions. I supports other GL libraries too. You can see here http://www.mono-project.com/Tao


    @grey: to my knowledge there are 2 ways do implement the same thing in windows.

    The first one is the same used in some trainers for games : trojian dll.
    You must provide a fake dll with the same name to the one you're emulating and the same exports. This dll must be in the same path of executable and it's used to override only wanted functions.

    The second is hooking. You can patch the loaded dll and inject your functions.

    In the first case it's impossible to use only C# as you need a native dll.
    In the second case it's possible to do that in C#, but it's platform dependent and it's really a mess.
    C# it's not the tool born to make memory patching and function hooking :)

    None of the mentioned functions would work in our case because when you compile with "embedded" orx option there is no plugin.dll and no glfw.dll.
    If none of this functions exports symbols it's not possible to make any function hooking as it's damn hard to get the address of the functions you wanna hook.


    @enis: abour your points: C# can inject but as said, for embedded compilations, it's really long and hard.

    If the linux distro is an lsb you could be right. What about different glibc versions? there are more than one glibc out there.
    We could distribute the library ready to link, and link it ony on installation, but as i said, on my "old" machine it takes 30 seconds to build orx and less than 5 to build my fake glfw.
    Why become crazy about that? :)






    Today I don't have much time to work on the callbacks side. I guess I'll ask you a lot of opengl stuff to understand a pair of things :)

    Cheers
  • edited September 2012
    Update:

    right now I have a semi-working orx window.
    All compiles, all callbacks are called, the opengl window is up and running and I implemented quite all glfw functions needed by the orxDisplay, orxMouse, orxJoystick and orxKeyboards plugins.

    I still have to clean a lot of stuff because I had to use platform dependent stuff but it will be easy to correct.

    If I find the time, this evening I try to port bounce and scroll demos in C# to see if they work.

    Bye bye
  • edited September 2012
    Another Update:

    orx_sharp.png

    As you can see in the attached image, I can load Grey's config file, and display it with the new plugin.
    I sill have to take care about few details to improve the usability of the OrxWidget class (the one that's rendering the scene) and I have to solve a little bug about resizing (may be I missed something from glfw).


    The example it's only 3 lines of code:
    OrxNative.orxViewport_CreateFromConfig("Viewport");
    OrxNative.orxConfig_Load("StaticScene.ini");
    OrxNative.orxObject_CreateFromConfig("Scene");


    During the week I hope to give you more good news.


    --- edit ---

    I corrected a bit the resizing. I still have a problem.
    When I resize the window, I see the contents are zooming.
    Do you have any idea?


    Bye Bye
  • edited September 2012
    Great job!

    Looking forward to trying it out :)
  • edited September 2012
    Is it possible to have a changelog of all exported functions added since the 1.3 version that's downloadable from source forge?

    Cheers
  • edited September 2012
    You'll need to do a diff on the all the headers for that.
    Good luck. :)
  • edited September 2012
    :(

    I'm at 50% of the library to interface orx library from managed code.
    I ported all the public structures and all functions based on version 1.3 (because I used code from Ocean).
    I'd like to synch all my imported functions with all the functions the actual orx code exports.

    Tomorrow I think I'll have a fully working library that could allow full usage of orx calling the APIs from C#.

    The other 50% I'd like to do is to divide the code in classes. I mean orxViewport_Create should be a "Create" static method of orxViewport class and should return a new instance of orxViewport.
    That could allow a cleaner OO coding if compared to the actual call to orxNative.orxViewport_Create().

    I'd be really happy if someone could help me discovering changes in:
    - exported orx apis
    - public structures
    - enums

    All I need is a test file with the names of modified things in a human readable format, rather than a diff file :)


    Cheers
  • edited September 2012
    Id love to get a copy of what you've already got done on the wrapper if at all possible? I've been looking into doing this myself but adding to your work seems the smarter idea to me :D
  • edited September 2012
    There's also http://code.orx-project.org if you want to host your work (can even be private) on bitbucket as part of the orx team effort. No obligation though. :)
Sign In or Register to comment.