ORX and QT


I've decided to try and combine ORX with QT.

QT is a libary which allows you to make nice-looking GUIs.

I've succesfully combined it with Cinder using an Open GL Widget.

I'm now trying to combine orx with the Open GL Widget, but as it's so event based, I'm wondering if it's even possible.

In any case, I'll have to re-do the entire initialization, and to start the openGL rendering on the widget. Even then I'm wondering whether/how I can get the mouse-pos through to the proper events.

I'll just keep working on it, so this isn't a specific question, but I'm hoping to get some replies and ideas how to work it.


  • edited June 2012
    I see that the orxModule_Init(orxMODULE_ID_MAIN) initializes a whole bunch of things. I can only assume this has to do with dependencies. However, I don't want it to initialize the window, as I want it to interact with the openGL widget. Should I initialise loose modules, and if yes, which?
  • edited June 2012
    The problem with QT (and a lot of other widget libraries) is it wants control of your soul--er, the entire main program loop. It wants to set up the OpenGL context itself and have full control of everything.

    I also looked into this when I was evaluating widget libraries and thought it looked like too much trouble for me (then again, I'm not so experienced with OpenGL).

    There are a few widget libraries designed to render into an existing OpenGL context and get out of your way. Of these, I've successfully got both libRocket and CEGUI working very well in Orx. Check out my other thread on libRocket if you're interested in using it, since some changes need to be made to the rendering code.
  • edited June 2012
    You could also say orx wants to control your soul instead.

    However, I can probably use CeGUI/libRocket for my goals, but I have more experience with QT (been using it for my graduation) so it's a shame.

    Oh well, I'll make do one way or another. Also stubbornly going strong :P

    EDIT: Related to this, does orx support multiple views and/or multiple physical windows?
  • edited June 2012
    True, it would be nice if someone figured out how to make this work. QT is complete and has a good reputation and support. So let us know.

    iarwain will probably have better answers to your questions.
  • edited June 2012
    Cinder works in a more traditional way:

    You have 'input' functions,
    You have a 'draw' function,
    and you have an 'update' function.

    This was easy to map to QT, because I only needed to set up the initialization manually, and then in the 'draw' part of the widget call the draw function of the Cinder class. For the inputs it was simply a case of mapping the QT input functions to the Cinder input functions.

    (If anyone has more interest in this, feel free to pm me or something, I can supply sourcecode and everything)

    I've been thinking about this, and the only way this could work with orx is to have a think about what orx does behind the scenes.

    In order to work with QT, the first thing necessary is making the screen initialization code optional.

    Secondly, the draw algorithm should be callable optionally. (in default situations, the main loop will do this)

    Thirdly, something should be done about input events.

    I think you'd have covered the most bases then, as most other things will just go along.
  • edited June 2012
    Wow, so many questions to answer in a single post, hope I won't miss too many of them. :)

    So, multiple physical windows in orx: none of the current display plugins handle that yet. And frankly I can't think of a game that take advantage of that.

    Multiple views, it depends on what you mean by views, orx definitely supports multiple viewports but I doubt that's what you meant.

    Orx is meant to be used primarily as an engine (as opposed to cinder that is a library). However you can use it as a library if you feel like it, it's just slightly more complex.

    You've noticed the main module initialization call. Well, that's where all the dependent modules are initialized. You can't change the internal module dependencies but you can change the main module ones.

    Actually, all that's written in orx.h is a simple convenience wrapper for initializing and executing orx but there's no obligation to use it if you don't need orx to work this way.

    An example would be the orxFontGen and orxCrypt tools that are only using a part of orx (ie. the config module and its dependencies). No windows/display init there.

    If you look in orx.h at orx_MainSetup(), that's where I define the main module dependencies for traditional orx uses. Up to you not to use that one but write your own.
    You can also copy/paste the content or orx_Execute() to your own main() function and adapt it to your needs.

    The difference between a module dependency and an optional module dependency is that if a standard dependency can't init, then your module won't init either, whereas an optional dependency failing to init won't stop your module to init.

    Orx also has input, draw (though it's called render) and update phases, and you can hook onto them via events.

    If you could post the sources it'll be easier for me to tell you how to do something equivalent with orx but here are some pointers:

    - you can register some clock functions between any of orx's phases to actually execute your code before rendering, after input peripheral updates, etc...
    - you can use the orxInput module to query the input periph state and then trigger the QT events manually
    - if you don't initialize the display plugin, you won't be able to use the render plugin either, nor the texture module, etc... so an easier way would be to use orx's OpenGL context instead of the widget one, I'm actually not sure why you need your own separate OpenGL context unless you want to render things outside of orx, but in that case I'd then do deferred rendering instead and a compositing step before screen rendering.

    - if you don't want orx to render anything, simply listen to orxRENDER_EVENT_START and return orxSTATUS_FAILURE, that'll skip the whole rendering loop

    If you could tell us more about what you'd like to make in the end, it'd be easier to give more valuable advices. :)
  • edited June 2012
    Essentially, an orx ini tool.

    I'm aware scrolls already has something like that, but i'm stubborn enough to try for myself. I can in fact probably do it without orx altogether, but then it's possible to get different results.

    Some ideas:
    A level editor with a separate window which shows the current tileset and allows you to choose which tile to place.
    An animation editor which creates ini files for animation for you.
    A nice gui to change the other ini options

  • edited June 2012
    I've been putting some effort into the same. I haven't announced it yet (still very early), but take a look:


    I do want to work with someone else on this if you're interested.
  • edited June 2012
    I'll have a look at your code tomorrow, but the basic stuff looks interesting. This is with librocket?
  • edited June 2012
    I hooked up window support with both CEGUI and libRocket since, prior to this, I had no experience with GUI libraries and wanted to evaluate both. You can switch back and forth by setting a pre-processor directive. The CEGUI support is a bit farther along.

    I'm leaning toward continuing with CEGUI only, but haven't made a final decision. It is not too terrible to support both. Just extra time.

    No matter whose approach we take, I hope we can do it as a community and get it done.. it seems like everyone who hangs out at the Orx forum long enough starts working on such a tool. We need it!
  • edited June 2012
    I'm impartial to either (QT all the way, but since that'll be quite another issue let's not) but I'd advise to choose one and stick with it, considering the users don't care which black box delivers the GUI elements.
  • edited June 2012
    Got it working now, I've perposefully dug out all the LibRocket stuff (reason: too lazy to download that too) and I've got it running now.

    The font did seem to be off; not sure what that was about (I'll attach a screenshot)

    orxcraft 111.8K
  • edited June 2012
    Right, you'll need the attached file in bin since it specifies a smaller font.

    Hopefully that's the only thing I forgot. Let me know.

    It's still immature code, but hopefully it's clear enough you can see what I'm doing and things make sense :)

    I would really like to get another person or two working on the project so we can take the Orx tools to the next level. If you're interested, you can fork it and we can come up with a plan.

    Thanks for looking! https://forum.orx-project.org/uploads/legacy/fbfiles/files/TaharezLook.zip
  • edited June 2012
    I was getting 60 errors a second saying that it couldn't read the bitmap. It's obvious I don't have the bitmap it's referencing, but then still it shouldn't give that warning every frame.

    Anyway, I'm willing to help, but I'm not yet going to commit on anything, as I've got some stuff going on for the next 2-ish months, so my effort would be on-and-off at best.
  • edited June 2012
    Gemberkoekje wrote:
    Essentially, an orx ini tool.

    In that case you can have a look to the Ocean thread as ainvar had to overcome similar issues with a similar project (and had to slightly modify orx to be able to embed orx's rendering within an other window).
  • edited July 2012

    I must admit this looks very interesting. Actually I like it enough to drop my project for similar tool written in python and PyQT (to be portable at least between linux and windows). It was designed to be engine independent and that decision haunted me on every step ;).

    I would be happy to help with work on OrxCraft. Unfortunately I don't have much spare time, still couple of hours a week should be doable (mainly on my train trip to work :D).

    So far I've created a CodeLite project to compile OrxCraft on linux. This was quite easy, some minor issues with file name cases. I've also refactored the project a bit, now that the data directories are expected to lie at the same path as the OrxCraft executable. I guess this would be actually the case for a binary release if it happens some day ;). While being at it I've put all the CEGUI xml files into the cegui directory.

    The code is available at https://github.com/graag/OrxCraft if you're interested. I tried to make the commits self contained ...

    Now I have a question about the GUI. Do you have some plan, vision, whatever? Or simply for now focused on the internals?

    I've made a quick mock-up of an interface that I would be happy to use with Orx projects. What do you think?

    edit: The file was to big to upload. Here's a link: https://picasaweb.google.com/lh/photo/YNueeo5TC9frKP2iAGyOQuxoTIxB2EMpJbkVvO4-vCU?feat=directlink

  • edited July 2012
    It's a shame to hijack this thread, but I'm not quite ready to announce OrxCraft in the projects section yet :D

    I saw you forked my github repo last time I was working on the code (last weekend). Thank you very much for your contributions so far. I will merge them in my repo.

    If you look at my github README, you'll see my very early development schedule. The short term plan is to get basic editing functionality for all the Orx structures and a stable code design. If you've been looking at the commits, you can see I'm still making pretty major changes. I haven't quite settled on the design of certain things yet.

    After the basics are done, the sky is the limit. Eventually we want something that can work together with ScrollEd for modifying objects and then placing them in maps. That is the grand vision, but I do absolutely want suggestions on the details of the GUI. I have some things in my head but no real concrete design planned yet.
  • edited July 2012
    BTW, thanks for the sketch. I will think about what you designed over the next few days and then probably PM you to talk a bit.
Sign In or Register to comment.