{"id":15758,"date":"2012-05-04T04:02:27","date_gmt":"2012-05-04T09:02:27","guid":{"rendered":"http:\/\/www.shamusyoung.com\/twentysidedtale\/?p=15758"},"modified":"2013-09-25T09:13:41","modified_gmt":"2013-09-25T14:13:41","slug":"project-octant-part-3-using-qt","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=15758","title":{"rendered":"Project Octant Part 3: Using Qt"},"content":{"rendered":"

Qt is a cross-platform application and UI<\/acronym> framework with API<\/acronym>s for C++ programming. In English, that means it’s a bunch of software that you can add to your project to make programs with a GUI<\/acronym> that will run on Windows, Linux, or Mac. This is actually a big deal. There’s a reason that so few programs are cross-platform: It’s hard to write code that will run anywhere. <\/p>\n

I know I keep sending you back to the Object-Disoriented Programming<\/a> post so often it sort of feels like a Rickroll at this point, but this is a really important problem. C++ itself is very barebones. It doesn’t load fonts. It doesn’t understand images. It doesn’t understand windowed environments. To do these things you need an SDK<\/acronym>. You’ll need one for each new thing you want to do. Each one might tie you to a particular operating system, and they’re very likely to conflict with each other in annoying ways. By the time you get all the stuff you need for GUI, images, sound, graphics, threading, and input, your project will be this Frankenstein’s Monster of sewn-together systems. And you haven’t even started coding yet!<\/em><\/p>\n

Qt manages to provide the really important systems: Image loading, font loading, windowed interface, user input, support for multi-threading, user settings (like ini files or registry entries) and file access. The only thing it lacks it a decent sound system. (It has a sound system, but it’s just for making popup-window type interface sounds. You can’t pan or attenuate, which means it’s no good for videogame sound effects.) <\/p>\n

For me, the real selling point of Qt is that it supports transparent windows over an OpenGL viewport. It has the works: spinners, combo boxes, scrollbars, checkboxes, edit fields, buttons, titles, sliders, progress bars, drop-down controls, etc. All of it seamlessly integrated with OpenGL. All of it perfectly cross-platform. And all of it can be completely customized with a few lines of CSS. Check it out:<\/p>\n

octant3_1.jpg<\/td><\/tr><\/table><\/p>\n

I can feed it some CSS and instantly turn it into this:<\/p>\n

octant3_2.jpg<\/td><\/tr><\/table><\/p>\n

This is an amazing bounty of tools. Qt solves all of this by bringing together all of the tools in a clean, self-contained manner. However, it has some costs…<\/p>\n

Problem 1: No access to the main loop.<\/h3>\n

In Project Frontier, my program runs the show. There’s a loop that cranks along. It looks like this:<\/p>\n

void run ()\r\n{\r\n\r\n  long    stop;\r\n  long    remaining;\r\n\r\n  while (!quit) {\r\n    stop = SdlTick () + 15;\r\n    ConsoleUpdate ();\r\n    SdlUpdate ();\r\n    GameUpdate ();\r\n    AvatarUpdate ();\r\n    PlayerUpdate ();\r\n    EnvUpdate ();\r\n    SkyUpdate ();\r\n    SceneUpdate (stop);\r\n    CacheUpdate (stop);\r\n    ParticleUpdate ();\r\n    RenderUpdate ();\r\n    Render ();\t\r\n    remaining = stop - SdlTick ();\r\n    if (remaining > 0) \r\n      Sleep (remaining);\r\n  }\r\n\r\n}\r\n<\/pre>\n
On line 8, my program looks at the clock and makes a note of the milliseconds. It sets a deadline for 15 milliseconds later. (The variable stop<\/code>.) Then it runs down the list of all the stuff it needs to do. When it gets to line 16 it calls SceneUpdate, which is the heavy-hitter that builds and loads sections of terrain.  “Hey, go ahead and do some building now, but don’t go beyond stop<\/code>!” If there’s any time left over, it’s given to the caching system. Once everything is done, it renders the scene. <\/p>\n
After the rendering is all done and the player is looking at their shiny-new frame, the program looks at the clock.  Are any of those 15 milliseconds left? If so, put the program to sleep until the time is up. This will limit the game to 66<\/acronym>FPS<\/acronym>.  On a slow machine, the loop will run as fast as it can, and make the game as smooth as possible given these limited resources. On a fast (or just mid-range) machine, the program will self-limit to avoid devouring 100% of the CPU. It’s not going to put your graphics card into overdrive trying to draw 500 frames a second, and it’s not going to waste time meticulously simulating the particles in single-millisecond increments. <\/p>\n
This is actually a very primitive timing loop. In a more robust system you might have multiple threads. Or you might run different systems at different framerates. Some systems NEED to update every frame, but they barely need any time. Other systems can wait if things are busy. Still others only need to update every couple of seconds. You want to keep the “burst” activities early in the loop. If it takes 10ms to load in a chunk of data, make sure that happens early in the loop so the more flexible systems can compensate. You don’t want to run into a situation where you start that file load with only 3ms left, thus pushing you over budget and making the framerate uneven. <\/p>\n
A good timing system will make sure the various subsystems all get the time they need without needlessly wasting CPU resources.  It can be tricky to do all of this and<\/em> keep the framerate smooth and<\/em> keep the heavy systems from choking off the lesser ones. <\/p>\n
In Qt, I don’t have this kind of freedom. When you build a Qt application, Qt runs the main loop, and it manages the CPU usage. It owns the clock. Your program is just one bullet item on its to-do list.  You have to request that it give you a slice of CPU time.  When your turn comes up you’re free to take as much CPU as you want, but Qt decides when you get a turn. <\/p>\n
This makes it very difficult to manage time properly. Basically, Qt calls your program when its time to draw. Actually, Qt calls your program once the rendering loop has begun, which kind of puts annoying limits on how you can structure things. It’s calling your program from within it’s own render loop. You have to hurry up and process all your crap, then draw the scene, then surrender control back to Qt.  <\/p>\n
If the framerate is too high, you can’t refuse to draw the scene, because Qt has already begun the rendering for you. If you abort now the user will end up looking at a blank frame. Worse, the frame doesn’t update until you surrender control back to Qt. If you go to sleep () for a few milliseconds, you’re delaying the display of the stuff you just drew.<\/p>\n
You might be tempted to use two different bits of code: one for drawing and one for background processing.  You can say how often you want them to run, but you can’t guarantee<\/em> that Qt will call them both, or ensure they will be called in the proper order. <\/p>\n
I should probably fiddle around with the timer now and see just how much time Qt eats and how reliably it will share the CPU.  That will give me a sense of whether this problem is inconvenient or crippling. <\/p>\n
Problem 2: The Qt IDE is not great.<\/h3>\n
In the old days, programming environments looked like this:<\/p>\n
octant_ide1.jpg<\/td><\/tr><\/table><\/p>\n
But then some smarty-pants invented widescreen monitors, and suddenly things looked like this:<\/p>\n
octant_ide2.jpg<\/td><\/tr><\/table><\/p>\n
Now we have all this space that’s going to waste. This isn’t like word-wrapping text, where making the window wider means that the words will just expand across the page.  In programming, things are broken into lines according to a very deliberate system.  You CAN turn this:<\/p>\n
\r\n\/\/Moving up & down while flying\r\nif (flying) {\r\n  if (InputKeyState (Qt::Key_Space))\r\n    movement += GLvector (0, 0, move);\r\n  if (InputKeyState (Qt::Key_Control))\r\n    movement += GLvector (0, 0, -move);\r\n}\r\n<\/pre>\n
Into this:<\/p>\n
\r\n\/\/Moving up & down while flying\r\nif (flying) {  if (InputKeyState (Qt::Key_Space))    movement += GLvector (0, 0, move);  if (InputKeyState (Qt::Key_Control))    movement += GLvector (0, 0, -move);}\r\n<\/pre>\n
…but you shouldn’t do so unless you have combat training, because the other programmers will try to kill you for it. Readability is king. That’s not hyperbole. In a real professional environment, carefully commented and neatly structured code with a couple of bugs is worth vastly more than efficient and bug free code that nobody can read. Someday someone will have to make some small change to the code, and the cost of modifying unreadable code is large, bordering on the cost of a re-write.  <\/p>\n
ANYWAY.<\/p>\n
So now we have this big expanse of whitespace beside our code.  The obvious solution is to just add another editing window over there.  This is actually really useful.  Very often you’ll be writing in one document while consulting from another, and now you can have both of them onscreen together!<\/p>\n
octant_ide3.jpg<\/td><\/tr><\/table><\/p>\n
In VS 2012<\/acronym>, you get these tabs at the top of the screen, one tab for each open document.  You can click between them and drag files from the left window to the right as needed. That tall window on the far left is a list of all files in the project. If I click on one, it will find the tab where I already have it open, bring that tab to the front, and put the focus there so I can begin working.<\/p>\n
In Qt, you don’t have tabs. You have a drop-down list. So now one action (click on tab) is replaced with three (click on list, scroll down to desired document, select) which is a pain. So you’ll use the list on the left. But when you click there, it will open up the document in whatever window you were last using – even if the document is already open on the other side<\/em>.  Instead of jumping TO a window, it makes a NEW window, and you can end up with the same document open on both sides of the screen. This is absurd.  When you realize your mistake your first instinct is to close the one you don’t want, which will result in Qt closing both of them<\/em>, on both sides of the screen.  There’s no way to drag files from one side to the other.<\/p>\n
octant_ide4.jpg<\/td><\/tr><\/table><\/p>\n
This really hurts my workflow, and this is just one of many such flaws. <\/p>\n
And yes, you CAN use Qt in Visual Studio, but not if you’re using hippie freeloader edition<\/a> like I am. And the non-free edition is hundreds of dollars. And even if I owned it, I’m not sure how well Qt and VS work together in practice. <\/p>\n
In short, these problems are really annoying, but it’s pretty hard to complain when you’re looking at a full-featured development environment for $lolfree. I’m already getting more than I’m paying for. Still, I guess I’ve been spoiled by MS tools over the last fifteen years.<\/p>\n
3. The Compile Process is… Unorthodox.<\/h3>\n
How C++ programming usually works: You type a text file. Then a compiler is run on the text file. If there are syntax problems, it lets you know where.  If not, it builds an object file.  So compiling the text file Avatar.cpp<\/code> will result in a file called Avatar.obj<\/code>.  This is the machine code for that specific file. Once all of your files successfully compile, the linker runs.  The linker gathers up all those .obj files and links them together to build AwesumGame.exe<\/code>.<\/p>\n
Under Qt, there is an extra step called the Meta Object Compiler<\/a>. It will compile Avatar.cpp<\/code> into moc_avatar.cpp<\/code>, which then builds avatar.obj<\/code>. Now, I’m not against this in principle. The meta-object thing actually saves you from writing a ton of stupid crappy boilerplate code usually required to set up a windowed interface with sliders and buttons and crap.  The problem is that this moc_avatar.cpp<\/code> file is the one fed to the real compiler, and so if there’s a problem the error message will refer to bits of code I didn’t write and can’t see.<\/p>\n
In general, the error reporting in Qt is just a lot more cryptic and obtuse. Which is saying something.  Compilers are notoriously confusing.  It took me ages to get a feel for all the ways the error messages can steer you wrong when you’re trying to track down a problem.<\/p>\n
4. In conclusion.<\/h3>\n
What? I’m supposed to be leading up to some kind of point? I don’t know, man. On one hand you get portable code, a dozen tools that would be really annoying to integrate in a standard environment, a configurable GUI, and solid documentation.  On the other hand, you lose control of the loop, you’re stuck with a fiddly work environment, and the compiler expresses itself in circular nonsense like it’s the Oracle from the Matrix.  <\/p>\n
In defense of Qt, it’s not designed<\/em> to be a game engine.  It’s an application development platform that just happens to have 80% of the tools you’ll need to make a game. On the other hand, I’m dreading moving back to Visual Studio and resuming the task of getting a set of image, font, and GUI libraries that don’t conflict, tie me to a given platform, or infuriate me. (The GUI is the worst one. They are all appalling. Yes, all of them. Even the one you think isn’t too bad. It’s actually terrible.) <\/p>\n
I was seriously considering ditching Qt until yesterday when I released the source for Project Frontier. After watching the community slam their heads into stupid, annoying, pointless, trivial, and frustrating difficulties in porting the code, I’m starting to think I’d rather not leave any more messes like that. I can see some spots where I got lazy and my ten-minute corner-cutting cost everyone else an hour.  I feel bad about that. I’m really gratified that despite the headaches, people are still willing to work through the hassle just to see it work. Still, even overlooking my slacking – this stuff is a stupid pain. It’s easily the worst drawback of the language, far more serious than pointer arithmetic,  ambiguous grammar, or any of the other things people cite when complaining about C++. <\/p>\n
If Qt could prevent or even alleviate these problems down the road, then maybe it’s worth the hassle. I’m content to stick with it for now. If I run into some hard limit and Qt just can’t deliver what this project needs, I can just walk away from the whole thing.  I should be working on my book anyway. <\/p>\n
Next time: We’ll add some cool stuff. <\/p>\n","protected":false},"excerpt":{"rendered":"
Qt is a cross-platform application and UI framework with APIs for C++ programming. In English, that means it’s a bunch of software that you can add to your project to make programs with a GUI that will run on Windows, Linux, or Mac. This is actually a big deal. There’s a reason that so few […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[233],"class_list":["post-15758","post","type-post","status-publish","format-standard","hentry","category-programming","tag-octant"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/15758","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=15758"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/15758\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=15758"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=15758"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=15758"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}