Important: Please read the Qt Code of Conduct -

Embed custom game engine in QTWindow

  • HI everyone!
    I wrote a small game engine and would like to use QT for it's tools. The engine is compiled as a .lib file and has no direct implementation for a "window". It uses instead a pure virtual class. I've successfully implemented a GLFW window that implements the pure virtual interface. It works like a charm.

    Here is how it is designed:

    The engine expects a IWindow implementation to use as render target:

    GameEngine gameEngine(IWindow& window );

    Than it runs the Game width, int height, const char* title, Game& game);
    This runs the game until IWindow.shouldClose() returns false;

    1 -The first problem is that QT manages the application loop via QApplication::exec(), So i can not run both! How to integrate both loops ?

    2 - The engine uses GLEW to bind to opengl core profile calls. Is it a problem ?
    3 - I saw some QT+OpenGL examples on the web, using QGLWidget. It works, but the drawing is triggered by QT when the control needs updating. Is it possible to use QGLWidget but trigger the Draw from somewhere else (like my engine render loop) ?

    I know all 3 questions are related and probably one problem leads to the next one. I really appreciate any good hint regarding these questions.

  • Moderators

    Hi, welcome to devnet.

    1. A better and more portable design would be if an engine did not run its own loop. The most popular way to do that is to provide a kind of Initialize(), Frame() and Shutdown() interface that you could call from a loop provided by whatever windowing framework (most of them usually have that). The Frame() part would measure the time elapsed from last frame and advance the states proportionally to that.
      If you don't want to go that path (just make sure you really don't) you could also run the two loops in parallel, starting your engine's loop in a worker thread. This leads to some synchronization issues, but with some work could be manageable.

    2. Again - it's better if the engine does not provide it's own OpenGL bindings but uses the ones provided by the windowing framework (e.g. QOpenGLFunctions in case of Qt). There should be no problem in using GLEW along with Qt, just make sure you do your GLEW/OpenGL calls with a current GL context provided by Qt.

    3. QGLWidget is replaced now with a more modern QOpenGLWidget. If all you need is a window and input management (like with GLFW) then consider using QWindow with an OpenGL surface format instead. You will get better performance and drop the requirement of QtWidgets module.
      As for triggering the update - there's an update() method for that. You can call it how often you need and it will schedule OpenGL painting. The usual way to tackle this is either using a timer or calling update() at the end of the painting method to schedule updates "as often as possible" i.e. as often as v-sync allows.