Hey all. I am begining development on a game and I am currently in the process of choosing a good UI engine (or deciding if it's worth to roll my own). My UI panels and controls need to be highly customizable, almost to the level that you can customize UIKit for OSX/iOS. I also want to do this without sacrificing the ability to manage my own main run loop. I am considering Qt, as it seems to have everything I want out of a UI engine, but one of the major drawbacks I see is that it wants to manage the main run loop. I know you CAN just call QCoreApplication::processEvents, as this is exactly what QApplication::exec does, but I'm just not sure yet if Qt is the right engine for a game, or if it's truly geared toward applications.

I just want to pick the brains of the people on this forum, and possibly get a nudge in the right directions. Is Qt a good choice for a game UI? What are some other good options that provide a high level of customization without sacrificing control over the main run loop?

Just as an FYI, I will be building this application entirely in OpenGL. One day I may support DirectX, but for right now I'm trying to reach the largest audience possible by focusing on multiplatform systems. However, the ability to support DirectX is somethign I do want to consider when choosing a UI. I don't want to get married to somethign that can only work with OpenGL, then I want to build out the DirectX layer and I have to ditch my whole UI.

Anyway, thanks for reading, and I look forward to hearing some opinions. Thank you.

-Adam

If you read Shamus Young's blog, awhile back he started a game project using Qt, and determined that it was just too greedy for his performance needs. The profiler he built showed Qt taking an inordinate amount of time to do its stuff, even more time than rendering. I suspect that this will probably be the case with most projects.

Qt is a non-trivial framework built for a specific purpose. That purpose is not games. When your UI is eating more time than your render, you have a problem. If you want to support both DirectX and OpenGL using a framework designed for games, you can check out Ogre3D, Irrlicht, Urho3D, etc... All three of those, at least, provide both DirectX and OpenGL backends that let you program your game the same regardless of whether GL or D3D are used behind the scenes.

Thank you for the response. That was exactly what I wanted to know about Qt, and confirm my suspicion that it just isn't meant for games. I've considered using a framework, but I think I'm going to roll my own, as the goal of this project for me is to learn about game engine design rather than just making a game and getting it to market as fast as possible, I just didn't feel like writing my own UI elements such as textfields and scrolling panels as well, but it seems like unless I want to use a framework that takes care of all the heavy lifting, I'll have to roll my own or use the OS standards. Thanks for the info.

The general guideline is to write games, not engines. If you set out to merely write an engine, you'll end with just another engine. It'll probably be an undirected mess, good for tech demos but not much else. Assuming you even "finish" it. (I use quotes, because these sorts of hobbyist things are never finished; they tend to just dribble away). Write a game, write another game, write some more; eventually you'll have a pretty good idea of the kinds of things you use often (engine stuff, so to speak) and the kinds of things you probably won't reuse.

You can dump all that reusable stuff into a folder somewhere and call it your engine, maybe work on refactoring parts of it in between projects, but here is the thing I've discovered about engines: the more you put into them, the less flexible they turn out to be. You can see this in action in many of the available third-party frameworks. The more they try to do, the more they lock you into doing things a specific way. Your own engine, if you still choose to write one, will be the same. There will come a time when you will set out to write a different kind of game from what you've been writing before, and it will probably happen that the engine you so painstakingly crafted isn't suitable and you have to start from scratch. Maybe some parts of it will be useful; unfortunately, you spent so much time in between projects refactoring it that you inadvertently introduced a whole boatload of dependencies that you now have to sort through and extricate.

If you read Shamus Young's blog, awhile back he started a game project using Qt, and determined that it was just too greedy for his performance needs. The profiler he built showed Qt taking an inordinate amount of time to do its stuff, even more time than rendering. I suspect that this will probably be the case with most projects.

Qt is a non-trivial framework built for a specific purpose. That purpose is not games. When your UI is eating more time than your render, you have a problem. If you want to support both DirectX and OpenGL using a framework designed for games, you can check out Ogre3D, Irrlicht, Urho3D, etc... All three of those, at least, provide both DirectX and OpenGL backends that let you program your game the same regardless of whether GL or D3D are used behind the scenes.

I have similar experience. I work as a technology lead on an open source project realXtend Tundra, which uses both Qt and Ogre. I have worked on implementing several rendering engines on various console architectures in the past (a sneak-peek on the latest I'm brewing, at very early stages: gfxapi docs, implementation status, online feasibility demo), and worked on a number of other graphics libraries as well. If I had the resources, I would not hesitate a moment to take up the effort to rid the Tundra codebase of both Qt and Ogre. Performance-wise, they are both completely unsuitable for real-time (possibly mobile) targets. If your performance goals make you worry about operations which take a millisecond to run, I recommend avoiding both Qt and Ogre.


Qt has significant performance problems with UI (both 'standard' and graphicsview-based), its internal event system, signal-slot architecture and the QtScript system. It offers a tremendous amount of features that'll get you implementing about anything very fast, and allows you to be very productive, but it's very traditional CPU-based when it comes to rendering, and it does not offer a UI system which was designed ground-up to be rendered on the GPU - those were bolted on top later on. If you're hoping to do game UIs with Qt, expect to see a lot of time spent in codepaths like this and this. If you're hoping on its GPU-based render systems, you'll be sure to see something like this and this. Qt 5 is bringing in a new UI system that should be better designed for GPU rendering, but I wouldn't hold my breath, especially since Nokia's gone Microsoft now. Consider using librocket or clutter or some others if you need performance, and/or are aiming for mobile.

Ogre is a relic. a legacy. a dinosaur. a false hope. If your dreams are at Crysis or Unreal, or you need a rendering engine that is stable, mature and fast, don't go for Ogre. Its design is extremely design pattern-driven, it fails at batching, it burns performance in poorly designed structures and cache misses. It's a complete opposite of what a nimble data-driven 3D engine should be. It would probably be a perfect example of Mike Acton's "Typical C++ Bullshit". It crashes in situations that should be easily validated, and silently fails or gets stuck in more subtle scenarios. The strive for extreme genericity, and many years of legacy artifact design has made it a monster. I believe metrics like KLOCs/feature or bugfix-to-new feature commit ratio are the keys for showing how arcane Ogre has become.


I have spent several weeks during the past years while running the project on investigating Ogre performance and stability issues. There's no end to them, and the more that I've familiarized myself with the codebase, the more I want to just delete all lines and rewrite it all. I do not recommend Ogre for anyone for any type of project, no matter how simple it is.

Some alternatives I think that are worth considering are Unity 3D, Urho 3D or SlimDX. If you do non-realtime desktop software, Qt is fine (in fact, it's excellent!). But never use Ogre, for anything. At least not before you've used Unity 3D for a few weeks to see how it compares.

I've kind of always suspected that about Ogre3D, despite it's popularity. I've never really used it, but skimming the docs for it is kind of a scary nightmare. I think Irrlicht might suffer from a lot of the same cruft, if on a smaller scale.

I do like Urho3D. I think that thing has some potential.

The general guideline is to write games, not engines. If you set out to merely write an engine, you'll end with just another engine. It'll probably be an undirected mess, good for tech demos but not much else. Assuming you even "finish" it. (I use quotes, because these sorts of hobbyist things are never finished; they tend to just dribble away). Write a game, write another game, write some more; eventually you'll have a pretty good idea of the kinds of things you use often (engine stuff, so to speak) and the kinds of things you probably won't reuse.

You can dump all that reusable stuff into a folder somewhere and call it your engine, maybe work on refactoring parts of it in between projects, but here is the thing I've discovered about engines: the more you put into them, the less flexible they turn out to be. You can see this in action in many of the available third-party frameworks. The more they try to do, the more they lock you into doing things a specific way. Your own engine, if you still choose to write one, will be the same. There will come a time when you will set out to write a different kind of game from what you've been writing before, and it will probably happen that the engine you so painstakingly crafted isn't suitable and you have to start from scratch. Maybe some parts of it will be useful; unfortunately, you spent so much time in between projects refactoring it that you inadvertently introduced a whole boatload of dependencies that you now have to sort through and extricate.

I appreciate everything you're saying, and I believe you are right if my goal is just to make games. However, it is not. I am not merely setting out to make a game. I am setting out to learn everything there is to know about making games. I don't see any other way to do this than to write an engine, and despite the obvious problems my engine will have, I believe that there is no better way to become a true master of any skill than to dive into the hardest task and own it. I am not going in ill equipped. I will be learning from the best through books, and hopefully this forum, and I think what I end up with will be something that while not on the same level as an engine like Unity 3D, will be something that can run a complex game, and shows impressive skill.

However, there is one thing I did take away from your post, which is that making a generalized game engine is too difficult a task for one man. I think I will take this advice, and not be afraid to write my game engine to cater towards my master work, and accept that this game engine will probably only be suitable towards one game. If it turns out that I want to write a 2nd game, I will probably not attempt to build a game engine again, and use a premade one. But at least for this first game, I'm feeling up for the challenge.

Thank you for a great response.

[quote name='FLeBlanc' timestamp='1338563997' post='4945337']
If you read Shamus Young's blog, awhile back he started a game project using Qt, and determined that it was just too greedy for his performance needs. The profiler he built showed Qt taking an inordinate amount of time to do its stuff, even more time than rendering. I suspect that this will probably be the case with most projects.

Qt is a non-trivial framework built for a specific purpose. That purpose is not games. When your UI is eating more time than your render, you have a problem. If you want to support both DirectX and OpenGL using a framework designed for games, you can check out Ogre3D, Irrlicht, Urho3D, etc... All three of those, at least, provide both DirectX and OpenGL backends that let you program your game the same regardless of whether GL or D3D are used behind the scenes.

I have similar experience. I work as a technology lead on an open source project realXtend Tundra, which uses both Qt and Ogre. I have worked on implementing several rendering engines on various console architectures in the past (a sneak-peek on the latest I'm brewing, at very early stages: gfxapi docs, implementation status, online feasibility demo), and worked on a number of other graphics libraries as well. If I had the resources, I would not hesitate a moment to take up the effort to rid the Tundra codebase of both Qt and Ogre. Performance-wise, they are both completely unsuitable for real-time (possibly mobile) targets. If your performance goals make you worry about operations which take a millisecond to run, I recommend avoiding both Qt and Ogre.


Qt has significant performance problems with UI (both 'standard' and graphicsview-based), its internal event system, signal-slot architecture and the QtScript system. It offers a tremendous amount of features that'll get you implementing about anything very fast, and allows you to be very productive, but it's very traditional CPU-based when it comes to rendering, and it does not offer a UI system which was designed ground-up to be rendered on the GPU - those were bolted on top later on. If you're hoping to do game UIs with Qt, expect to see a lot of time spent in codepaths like this and this. If you're hoping on its GPU-based render systems, you'll be sure to see something like this and this. Qt 5 is bringing in a new UI system that should be better designed for GPU rendering, but I wouldn't hold my breath, especially since Nokia's gone Microsoft now. Consider using librocket or clutter or some others if you need performance, and/or are aiming for mobile.

Ogre is a relic. a legacy. a dinosaur. a false hope. If your dreams are at Crysis or Unreal, or you need a rendering engine that is stable, mature and fast, don't go for Ogre. Its design is extremely design pattern-driven, it fails at batching, it burns performance in poorly designed structures and cache misses. It's a complete opposite of what a nimble data-driven 3D engine should be. It would probably be a perfect example of Mike Acton's "Typical C++ Bullshit". It crashes in situations that should be easily validated, and silently fails or gets stuck in more subtle scenarios. The strive for extreme genericity, and many years of legacy artifact design has made it a monster. I believe metrics like KLOCs/feature or bugfix-to-new feature commit ratio are the keys for showing how arcane Ogre has become.


I have spent several weeks during the past years while running the project on investigating Ogre performance and stability issues. There's no end to them, and the more that I've familiarized myself with the codebase, the more I want to just delete all lines and rewrite it all. I do not recommend Ogre for anyone for any type of project, no matter how simple it is.

Some alternatives I think that are worth considering are Unity 3D, Urho 3D or SlimDX. If you do non-realtime desktop software, Qt is fine (in fact, it's excellent!). But never use Ogre, for anything. At least not before you've used Unity 3D for a few weeks to see how it compares.
[/quote]

Thank you for a great post, this answered many of the questions I was having. I've decided not to use Qt, and roll my own UI. It's not going to be the best of the best, but I think I'm going to learn a lot, and that's really what this game is about for me.