Some thoughts on SDL + Qt + OpenGL for a Game Engine

Question

I've been researching the ideal parts for a game engine which I'm building. At first I tried just going raw and writing everything from scratch using just the bare amount of native libraries such as Win32, X11, OpenGL, Glew, GLX, etc.

And then I realized this would take forever just for a game engine.

So, I'm looking into writing a game engine using OpenGL + SDL + Qt. The reason why I want to use SDL with all of this is because of its context creation and OpenGL initialization support. I like Qt's implementation (for the most part), but, honestly I prefer SDL. My main idea is to use Qt for strictly GUI development (such as in-game menus, debug consoles, HUD rendering, etc).

What I'd like to know if this is a good approach, and if not, are their any better approaches out there? If this is a good approach, what would be the best way to implement, not the engine per se, but the integration of the two. I read a similar question on SO dealing with someone who was writing a physics simulator and, essentially, was trying to accomplish the same thing, however he was using threading, which I'm not sure if I'll be using or not quite frankly.

Still, as far as I know, it seems like there are significant differences between a game engine and a physics simulator, and I'd like to know exactly what I'm getting myself into.

Some Thoughts

• I like the bare OpenGL implementation as opposed to Qt's, mainly because I feel like I have more control.

• I prefer to have more control over the main loop, hence why I'm using something like SDL and not Qt's implementations - the issue is I'm not sure if this actually is recommended considering how different the two are.

All in all, I'm sure some people would tell me to just use QWidget and let it be at that. The thing is that I'm relatively new to graphics programming in general, and feel as though learning the original API through raw opengl would be the best approach. If I'm wrong, however, then I definitely would like to know.

I know this question is rather broad and less specific, but I really need advice regarding this, and hope that this may somehow help another developer who's looking to do something similar.

It seems like this is definitely a hard topic to cover in terms of objectivity, so I'll state the criteria in terms of flexibility and raw opengl + GUI support, as that's really what I need.

Answer 1

And then I realized this would take forever just for a game engine.

Incorrect. It won't take forever if you have clearly defined goal or specification of final product. If you don't clear vision of what you want to get, then it will indeed take forever. There are game engines written by one person or small teams. One example is sauerbraten.

You should understand that engine is not the most important part of the game. Even if you have engine, you'll still need game assets - art, music, textures, sound. Acquiring them will be much more difficult than writing an engine - because it is extremely rare to have single person that can do it all well enough (so you won't be able to make them all yourself), their creation takes time, and there aren't that many free good resources for this stuff.

My main idea is to use Qt for strictly GUI development

Not exactly a good idea. While it is possible to integrate Qt into SDL, and use signals/slots (by providing custom event loop combined with SDL event loop), this way you won't get access to Qt widgets in fullscreen application. Fullscreen blocks everything, so for using Qt 4 for in-game GUI it is very likely that you'll have to design your own Qt-based GUI framework for SDL from nothing. Although this can be done, it will take time. You won't have this problem if application isn't fullscreen, though, but still Qt GUI won't be exactly suitable for this scenario. It makes sense to integrate Qt 4 into SDL application to get access to QFont/QSharedPointer/QString and similar "lower-level" classes, but if you're planning to integrate QWidget then it won't be worth it. There are few theoretically possible ways (I haven't tried) to wrestle Qt into submission and make its widget paint themselves within SDL screen, but I think this isn't worth the effort - solution will be either too complex, or too inefficient, or will have severe limitations.

A more realistic approach would be to stick with KISS principle. You don't need extremely flexible GUI library to make in-game gui. You need to make something that looks like window with a few buttons and behaves like that. Typically this can be solved with texture with few animated regions - without all the complicated GUI framework .

What I'd like to know if this is a good approach,

Integrating Qt 4 into SDL to use Qt 4 GUI within SDL application is not a good approach if your goal is to seamlessly integrate Qt 4 widgets into scene painted within SDL window.

and if not, are their any better approaches out there?

For a start you need to get a clear idea of final applications. If you don't have a good vision of final game, writing the engine for it will take forever - because you'll waste a lot of time implementing functionality you don't really need.

Answer 2

So, I'm looking into writing a game engine using OpenGL + SDL + Qt.

Qt and SDL don't mix. Qt does everything that SDL does, regarding window and input management. But Qt is terrible for a game, because it hides the event loop from you. For a game however you need concise control over the event loop.

I like the bare OpenGL implementation as opposed to Qt's, mainly because I feel like I have more control.

There is no "bare" OpenGL. You've to greate a window anyhow and SDL seems like a reasonable choice. BTW: There are special purpose GUI libraries, based on OpenGL, intended to be used for games.