Use Qt, something else, or roll my own?

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.

I've been writing my own recently, because I didn't find any of the existing libraries to be satisfactory. However, they may be of use to you. Look into Immediate Mode GUI's (IMGUI.) I don't like them, but many do, and they're definitely adequate for prototypes and mockups. Also, look into libRocket and Awesomium. I think they're pretty sweet -- too heavy for my needs, but extremely capable.

Qt is fine for games - the only possible problems come to the question of using the UI code in a game, and having it overlayed/intermixed in with the 3D graphics. Of course since that's what you're asking for, the responses have been relevant - but some of the linked negative Qt blog posts seem to write Qt as a whole off for games altogether, which isn't fair.

Qt is more than just a UI toolkit - it provides cross-platform windowing, networking, input, sound, fonts etc, all in a single library. So that's all the stuff useful for games, and at least as good as what you get in libraries like SDL. Qt can certainly be used for games in this sense. It is also fine for mobile, indeed, that's what Nokia used it for, to provide the primary API for the popular Symbian platform (I've used Qt for Symbian, Android, Windows and Linux). That Qt manages the main loop shouldn't be a problem - indeed, there are arguments in favour of this, for example it means the API/OS can manage better for battery life, rather than having to trust the programmer to get that right, which is important for mobile use. Why do you need control of the main loop?

It is incorrect to say that Qt wasn't built with games in mind, when it does have plenty of classes clearly geared towards that purpose. Whether it's the best API or not for games is another matter of course, but it's not that it was never intended for games.

So the problem isn't whether Qt can be used for games, but whether you can take advantage of the UI within the OpenGL window. I'm not sure if any UI designed for "OS friendly" UIs will work as well as the UIs that are designed to work with 3D engines - but on the flip side, you've got the cost that the latter don't tend to be as good in terms of the UI offered (which often isn't a problem for most games). This isn't a flaw with Qt, but something that no standard "OS friendly" API seems to offer.

Indeed, the blog post notes "So the real overhead of using Qt is only ~1ms per frame. That’s reasonable." He also notes that SDL would be no better - Qt still provides all the benefits of cross-platform windowing, network, input, fonts and so on, without having to need all the add-ons that SDL needs. Yet people still happily use and recommend SDL for games. The bottom line is that there doesn't seem to be a single API that can be used for non-game "OS friendly" application UIs, as well as being good for games (or is there?) - and the OP may well be better off with an API that is targetted towards in-game rendering.

(Another approach is to arrange your UI so that the UI surrounds the main 3D window, rather than having to be overlayed. For some kinds of games, this is fine - e.g., role-playing games, adventure; and anything you need to overlay can be left to more simple elements that you can roll your own. But if this isn't suitable, I'm not sure if any standard OS toolkit will be useful.)

If you choose not to use Qt for the UI, what are you going to use for all the other things you need (windowing, input, etc)? Qt is still a viable choice there

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.

Qt is open source, and is not dependent on Nokia's future direction.

That Qt manages the main loop shouldn't be a problem - indeed, there are arguments in favour of this, for example it means the API/OS can manage better for battery life, rather than having to trust the programmer to get that right, which is important for mobile use. Why do you need control of the main loop?

It is a problem for a real-time game if due to the Qt main loop & timer event implementation one cannot get a stable framerate at all. I'm clb's co-worker and thus have worked with the Tundra codebase as well, and there has been a problem with implementing a sensible frame limiting mechanism using Qt. Either one uses a non-zero timer period, in which case the application may sleep unnecessary extra time, or use a zero timer period, in which case the main loop runs as fast as possible, but there is the risk of the application actually choking on OS window messages. The "extra sleep" problem is actually worse in Qt 4.8, and partially due to that we rolled back to Qt 4.7.

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.

If you want to learn 'everything there is to know about making games, MAKE GAMES. not engines. with engines, you learn only a tiny tiny bit of games. essentially it's all the "i can code something a game could use without ever having to think about how to MAKE A GAME". essentially, it's an endless hiding from the real problems, the real knowledge to gather: the solving the hard parts about a game.

after you've written some games, you already have an engine in hand: the code you copied over from game A to game B to game C. there's not more to it.

want to learn to make games? why not making games, then?

I guess the OP meant to make a game from scratch, not to make a standalone engine. We are misunderstanding again because his/her mixing up terms.

It's perfectly okay to make a game from scratch without using engines if the main goal in not releasing a game, but to learn/whatever (i do that and I love it).
The problem is when a newbie (or pretty much anybody) what's to make a real engine (with the real meaning) into the air.

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.

I have some personal experience with exactly this like some of the other posters: Qt has some very nice features which make it tempting for game development, but you'll here over and over again in the horror stories that: "Qt is good at what it is designed for." Sadly, it is not designed for games.

I'm not going to go in depth about the issues, but basically (for me) it boiled down to bad / random performance and random system dependent issues that made trying to help bug reporters a nightmare.

The other issue is that QCoreApplication / QApplication end up being globals that are needed by most Qt modules, so if you decide to switch away from Qt in favour of something else for gui / input you'll still have to deal with QCoreApplication / QApplication.

[quote name='metsfan' timestamp='1338590724' post='4945445']
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.

If you want to learn 'everything there is to know about making games, MAKE GAMES. not engines. with engines, you learn only a tiny tiny bit of games. essentially it's all the "i can code something a game could use without ever having to think about how to MAKE A GAME". essentially, it's an endless hiding from the real problems, the real knowledge to gather: the solving the hard parts about a game.

after you've written some games, you already have an engine in hand: the code you copied over from game A to game B to game C. there's not more to it.

want to learn to make games? why not making games, then?
[/quote]

I think szecs' response is a better answer than I could personally give to your post, so I will refer you to his post, but I just want to add that the main things I want to learn about are:

-Managing scene objects
-Building an optimized resource caching system
-Building a robust scripting system

I know what your response is going to be, "No! You're crazy! Use an engine!". That's fine, do what you want for your projects, but my decision is made on this, and I'm actually really enjoying building my own system from scratch. I like working on low level systems. Making high level game logic isn't the only thing that interests me. Anyway, thank you for the reply, and best of luck.

after you've written some games, you already have an engine in hand: the code you copied over from game A to game B to game C. there's not more to it.

Actually, there is. The difference between writing things to be used by the specific game you're working on and "writing an engine" is that the later is about making those things generic and modular, whereas if you're in a "make games not engines" mindset you're not going to try to abstract the stuff you make from the specific game you're making, which will make it hard to reuse for a different game.

In my experience when you reuse code that wasn't designed to be reused it becomes increasingly painful because you are compelled to hack your way around the problems it causes, which will make it even harder to reuse it again for the next project etc.

However I do agree that doing that is probably a necessary experience to have before setting out to write "an engine" (aka a bunch of things you know you'll need in almost any game and designed to be reusable and generic), because it's the best way to know what you're going to need and also which pitfalls to avoid (because you have previously fallen in them).

[quote name='davepermen' timestamp='1339141498' post='4947306']after you've written some games, you already have an engine in hand: the code you copied over from game A to game B to game C. there's not more to it.

Actually, there is. The difference between writing things to be used by the specific game you're working on and "writing an engine" is that the later is about making those things generic and modular, whereas if you're in a "make games not engines" mindset you're not going to try to abstract the stuff you make from the specific game you're making, which will make it hard to reuse for a different game.

In my experience when you reuse code that wasn't designed to be reused it becomes increasingly painful because you are compelled to hack your way around the problems it causes, which will make it even harder to reuse it again for the next project etc.

However I do agree that doing that is probably a necessary experience to have before setting out to write "an engine" (aka a bunch of things you know you'll need in almost any game and designed to be reusable and generic), because it's the best way to know what you're going to need and also which pitfalls to avoid (because you have previously fallen in them).
[/quote]

Um, I think it's true when you are a sloppy programmer (I'm not calling you that!). If you are not a sloppy one, then the code you produce should be reusable (or easily modifiable to be reusable) by default even without the intention. If you properly use the "single responsibility" principle, your code is not flooded with globals, functions are small functions etc. Most reuse-candidate functions should be quite general ones anyway (setting up stuff, initializing common stuff, loading stuff, rendering common stuff and setting up common environments, input handling, messaging, debug/logging stuff, maths functions and helper functions, whatever).

Okay, I may be totally wrong, because I AM a sloppy programmer (but even I can reuse tons of my stuff with minor or no modifications).

Related to the Ogre/Qt vs something else discussion, there's a data point for comparing the rendering performance of the same scene in an Ogre-based scene viewer to a Urho3D-based scene viewer and a custom (not particulary optimized) geometry render loop on top of my gfxapi library posted at realxtend-dev mailing list.

An intrusive profiler system was developed and embedded into Ogre3D which is very similar to the one in Urho3D, and there's screenshots that show a breakdown of CPU time spent in different parts of the internal rendering loops in both Ogre3D and Urho3D. The results will probably make any programmer cry out "I want my milliseconds back!"

I think szecs' response is a better answer than I could personally give to your post, so I will refer you to his post, but I just want to add that the main things I want to learn about are:

-Managing scene objects
-Building an optimized resource caching system
-Building a robust scripting system

I know what your response is going to be, "No! You're crazy! Use an engine!". That's fine, do what you want for your projects, but my decision is made on this, and I'm actually really enjoying building my own system from scratch. I like working on low level systems. Making high level game logic isn't the only thing that interests me. Anyway, thank you for the reply, and best of luck.

No, I don't say "Use an Engine". I say MAKE GAMES. you can't learn to properly manage scene objects if you don't have a reason to manage them in the first place. You don't learn about wrong design if you don't use your design.

Create your own engine, but do it BY MAKING A GAME.

I never said, and never will say, use an engine. That's NOT the point. But you can not build a good car if you never ever testdrive it. You can't built a great pc together if you never ever turn it on.

Use your engine. Create games. And let the engine evolve while doing so. You will learn MUCH MORE. Because an engine is a tiny tiny tiny part of the logic that a game requires. And if you make games, you will have to learn ALL the logic. That will help you, learning much more (massively much more), and your engine, not falling apart on the tiniest first try-out.

Um, I think it's true when you are a sloppy programmer (I'm not calling you that!). If you are not a sloppy one, then the code you produce should be reusable (or easily modifiable to be reusable) by default even without the intention. If you properly use the "single responsibility" principle, your code is not flooded with globals, functions are small functions etc. Most reuse-candidate functions should be quite general ones anyway (setting up stuff, initializing common stuff, loading stuff, rendering common stuff and setting up common environments, input handling, messaging, debug/logging stuff, maths functions and helper functions, whatever).

To me, the whole point of "make games, not engines" is to get the game done, and therefore to have a deadline. Perhaps I'm wrong though, but personally I was never able to complete anything without a deadline.

If you make a game on a deadline, then you'll always end up at some point with a choice between doing things cleanly or making your deadline.

And if you have no deadline and take the time of making all your stuff reusable and nice, then imo you're pretty much writing an engine and a game at the same time.