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='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).

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.