Jump to content
  • Advertisement
Sign in to follow this  
metsfan

Use Qt, something else, or roll my own?

This topic is 2230 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. Edited by mdwh

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!