Improved support for writing games using Qt?

Published Wednesday September 16th, 2009
87 Comments on Improved support for writing games using Qt?
Posted in KDE, Qt

Hi, all.

Would it be interesting for us to add some apis, examples and demos that show how to write games in Qt?

No work is happening in this field right now, so this is just an early invite for comments.

For example, we could provide

* Physics engine integration, perhaps in-house, 3rdparty, plugin based?
* Collision detection system (a more comprehensive one than what we have already)

I’m aware of free and commercial APIs that exist already, does anyone have a favorite to recommend?

Any ideas? Anybody interested? Is this worth investigating? πŸ˜‰

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in KDE, Qt


llm says:

What i realy like to see is a variant of the Delphi based GLScene [] in QT

Its a very very easy to use 3D scene system

from the website:

GLScene is an OpenGL based 3D library for Delphi. It provides visual components and objects allowing description and rendering of 3D scenes in an easy, no-hassle, yet powerful manner.

ciao llm

kedadi says:

Absolutely. As a consequence, Qt will just become Qtier.

Nishant says:

I was waiting for this for ages!! … please do it.. And QtGaming(like the name?) module can be acepted as a windows only module, no need for making it multi platform, at least for the first version!!

LestorN says:

Nokia need game for phones? QtGame will be. Anyway.

mzalfres says:

Gaming support will surely make Qt more popular, although competition is strong here. I’d start with Linux version (windows family has enough gaming engines available). This seems to be broader problem – I have lots of friends who say – I’ll use linux when my games will run on it. They don’t want to play ten-years-old remakes but brand new games with all bells and whistles available from modern graphics. If Qt is going to start with gaming support it will be really big advantage for both Qt itself and linux environment.

…you’re not by any chance going to be in Munich the weekend leading up to DevDays 2009, are you? πŸ˜‰ We’re 12 people that’ll be joining up in Nokia’s offices (thanks Harald!) to talk about this πŸ™‚ In particular, what we’ll be talking about is… this: πŸ™‚

Callum says:

Not strictly game related but a fully supported way of rendering web content including plugins (Flash, Java, QuickTime) via Qt/WebKit into a memory buffer and the ability to inject mouse and keyboard events would be wonderful.

We have a working solution (minus most of the plugin portion) but something official would make things less complicated for us.

Benjamin says:

I would love to see that.

Physics engine can be interesting too in a UI. If each item of graphics view have a weight, and you can throw them πŸ™‚
It would be nice to have something to make the AI too.

versesane says:

Hello Andreas,

I work at a Indian Robotics startup named TRI and have made a Visual Programming Language for kids to use our robotic kits using C++/Qt entirely based on QGraphicsView Framework. We were thinking of adding simulation to it. After looking at the physics engines based in C++ and also weighting whether we should develop something inhouse on top of Qt/C++ we are on the verge of going with the former. Def having some minimalistic gaming engine in Qt/C++ would make the whole game/ 2D simulation based software n top of QGraphicsView Framework feasible. Let me know if you want to see some video of our existing software to know what I am talking about.


Andre says:

Bullet Physics is a great engine and might be a good candidate for physics inclusion. This is also great btw:

Alban says:

Isn’t it what Gluon is supposed to be already ?

Giuseppe says:

Just to start, we need:
1) a modern audio playback system, like OpenAL
2) a modern physics engine, like bullet or ODE

PasNox says:

It’s definitively a must have feature !
I have starting a game with Qt 4, i have reporting joystick support for later for now.
Having a QtGame module will for sure add support for joysticks and make me happy to not write it πŸ˜‰

Chakie says:

Yes, this would be very interesting. Qt has in these last few years become a very viable platform for games, especially strategy games which are close to my heart. Depending a bit on what QtGaming would include, I think this a very good move,

dridk says:

Gluon API support sound with openAL, joystick and many input supported by evdev and finally Graphics with openGL and Box2D, and nextly using ODE.

this API currenty on KDE, can be ported on Qt4 only and Nokia phone 900

e8johan says:

Me wants STOS/AMOS like API for Qt. I especially remember loving the ability to write a small string commanding the movement of sprites and just creating them on the fly. Collision detection then told me which to blow up/kill and so on. Very nice.

yan says:

I thinks, your proposition could be interest 3D development too.

We have create a thread from the French developer community :

When we are a lot of suggestion, we’ll send these πŸ˜€


Nimmersatt says:

This is really a great idea of yours and I would really appreciate it to see more gamesupport in Qt. As Callum said this might be helpfull for other projects as well.

And please donΒ΄t listen to Nishant (nothing personally against you), there are gamers on every platform ! I myself am using a PC as well as a Mac for playing games. Multiplatform Qt gaming support for all ! πŸ˜€

I’ve never used it, but it’d probably be a good idea to see if anyone else has anything to say about PAL (Physics Abstraction Layer). Assuming it’s decent, I like the idea of being able to code for a portable API and select physics engines at runtime if need be.

Ola says:

I’m working on two commercial gaming projects that use Qt, both are running on Linux, Mac and Windows.

Most important for us would be an easy and high performance way to have Qt widgets/windows as an overlay on a OpenGL scene. I recently found the openglcanvas demo – is this the way it’s going to be? Doing it this way requires a rewrite of any code currently using the GLWidget, so I’m keeping it on hold for a little longer – is there something more coming in 4.6?

– Platform-independent support for game controllers (joysticks etc) would be very helpful, that would be something I would like to see in Qt. A standard way of assigning controllers to various functions would be nice too.

– Also, some demo of your idea of implementing keyboard input with the lowest latency possible (for character control, etc), including the use of modifiers (shift – w = run, etc), several keys down at once, etc.

– Maybe the keyboard could be treated as a game controller, so that the API would be similar to when using a gamepad? It would be very nice to not have to write code twice like we do now (for keyboard and gamepads).

Bullet is the best supported and actively developed open-sourced physics engine at the moment, so I’d recommend using that. You can do 2D with it too, and it’s also possible to just use the collision detection. Most people I know are leaving ODE for Bullet now.

Contrary to what another poster wrote above, cross platform support is very important. It’s our main reason to use Qt in the first place (+ it’s awesome). So please, no windows-only code, there’s enough of that already.

Szabolcs says:

I once tried to make an animation (of “boids” flying around the screen) using Qt on Windows XP. I used QTimer events to draw the frames. This did not yield a smooth looking animation, probably because the resolution of QTimer on WinXP was only 15 ms (as measured on my machine). Thus failing to draw a frame precisely on time introduced a (definitely noticeable) delay of 15 ms.

It would be nice to see some tutorials on how to do this properly, i.e. how to get a smooth-looking game-like animation of around 30 fps.

boulabiar says:

Hi all,

The question is to write a new Physics engine from scratch ? or to make the integration of other engines easier ?
There is a big difference between these !

Some people are using already other engines, and the code to be included in Qt will be huge. (you can see the size of other engines)

I propose to add some glue code and Qt abstraction API on top of libraries where the user can decide which API he can use.

eric says:

Hi there!

Great stuff you guys are doing. I am currently looking at OpenCL and CUDA from Nvidia as computational engines to assist my applications. I am doing image processing, large calculation for dynamic fluid simulations and other math stuff. The mix of OpenCL and OpenGL is really neat and it would be really cool to get some kind of framework from Qt that leverage GPU.

achipa says:

Is this worth investigating? Is the space pope reptilian ? I found it already strange that with all the Symbian love lately nothing has been done to make bring not-just-simple-2D-graphicsview games to the (coding) masses. I would like to say use existing ones (preferably via plugins) but if it’s important to have it also on Maemo and Symbian, an in-house solution would also have it’s advantages.

BlackCoder says:

Hi guys,

Based on my experience I would strongly recommend ODE for as a physics/simulation engine. It’s been widely used in many games and simulation projects ( and is an active projects with lots of improvements and support over the years. For a simple, stand alone collision detection library, I would recommend either PQP or SWIFT++, both can be found here .


SR says:

As for Ogre3D-lovers, qt is already a good “host”-framework (to nest a Ogre3D Renderwindow in) and a good Gui.
Qt-side work at this field is definitly a “must have” (^_^)

hugo says:

If you are going to write a new Physics engine can you make it like NVidia Gelato where you can choose to run it on graphics hardware (GPU) or run it on CPU.

muenalan says:

YES^3! Whishlist:
– SVG-centric (has animation already, go use Inkscape for items etc),
– SVG tweening
– having Flash-like things in mind.
– plugin-based physics, some minimal Qt 2d physics for a start, so one can come up with a wrapper for bullet3d or so as well.

Speedwise, surely the QGLWidget/GraphicsScene/View combo needs more improvement as it seems still rather slow compared to a native opengl app.

Andreas says:

Wow, lots of comments already! Just want to restate that this isn’t a “and btw we’re already done” posting, we truly have not investigated anything in this area yet. So it’s great to see that there’s so much interest and people have so many references we can dig into.

@LestorN: Actually, so far no features have gone into Qt that only make sense for Nokia that I know of. Feature discussions are as vigorous today as before, nothing has changed. And I don’t feel like Nokia, nor any of our users, customers, or even our own developers, dictate features in Qt.

@Alban: If we start doing anything in this direction we’ll _definitely_ talk to people behind Gluon first thing!

Does anyone have ideas of what we could investigate other than physics, 3D and collision detection?

john says:

Being a beginner, I have much fewer requirements. I once thought about how to make a bomberman clone but couldn’t even figure out how to get at the keyboard to move the bombermans. Would I set up a timer which asks for the keys being pressed? Or are there some methods to overwrite which would be called when the keyboard’s key-repeat sets in?

Just some small samples how to do this would be great. Collision checking would also be nice, of course.

GLDev says:

That’s a great idea. but:
* instead of only seeing GAMES as the applications, see the whole range of apps that could use a physics engine integration and keep those in mind when implementing the new module: CAD and engineering applications, automation and simulation, 3D animation, special effects, desktop eyecandy etc. There are lots of professional application fields and other applications that would benefit of such a physics module, not just games.
* do not under any circumstances make the mistake (suggested by one reply above) to make this module Windows-specific. The first reason why developers use Qt is precisely to write one code and run it on many platforms. Besides, for all professional use cases of a physics engine, cross-platform is an absolute requirement!
* either choose a physics engine that is suitable for more than just gaming (for example “Open Dynamics Engine” seems to also be used by quite a couple robotics simulation projects) or, better, do a modular glue system that uses external engines as a back-end. This would be particularly interesting if it could use GPU-powered physics engines, such as NVidia’s PhysX.

Scorp1us says:

I’d rather Qt focus on other stuff. Like:
– XML xpath/query support WITH node manipulation in DOM like how MS does it. (Manager/navigator classes)
– proper SOAP support via QObject proxies
– OpenSource replacement for Flash done in Python or QtScript. (Finally do-able in 4.6!)

PyGame already exists for easy game writing.

Darryl says:

Have you looked at Simple DirectMedia Layer (SDL)? Nice thin layer to the platform below, cross platform, and very popular. Many games ported to Linux use this.

Chris says:

Before you start integrating other APIs, how about adding some control over the system video modes? It’d be nice to switch resolutions when using OpenGL for full-screen games.

Also, I second the request for OpenAL. Some support for joystick-like input devices a la DirectInput/XInput would be nice as well. I’d rather have the cross-platform I/O primitives than physics engine integration at first.

Raptor_i says: integration could be nice. Haven’t use it much but is seems nice with plugins and all.
There is also some preliminary stuff tested with Qt.
License wise it could usable also.

miv says:

I would love to see some improvements in the QGLWidget and in the OpenGL examples. In the current examples a separate drawing thread is not used at all. But when you want to draw something with 60 Hz without slowing down your GUI thread, that is how it must be done. So support for separate drawing thread and flicker free resizing in QGLWidget would be quite nice.

mh says:

Something like Microsoft XNA Game Studio would be nice πŸ™‚

icastano says:

In order for Qt to be useful to game developers it needs Direct3D integration (9, 10 and 11). A good demo would be game-like user interface overlayd on top of the 3d view, or integrated in the scene using the D3D and OGL backends. For most developers its also critical to have support for most popular consoles, which means support for the XBox variant of D3D, and the propietary sony APIs.

neuromountain says:

Anything you can do to ramp up gaming and the supporting math and physics would be excellent. Interfacing to existing libraries like HOOPS, Crystalspace, G3D, or Ogre could be an option, or streamlining the hooks into the Coin3D scenegraph lib might help as well.

I think that really good, intelligent, and quasi-immersive 3D web interfaces, the development of which will require the same skills as any gaming programming, are a market void waiting to happen. Anything you can add to speed the development of these will set you apart from the pack. the Quaternions and n-D matrix transforms in 4.6 are a good start.

Nick Porcino says:

I would caution strongly against adopting a particular solution for physics, collision, audio, rendering, and so on. ODE, bullet, and so on all have great merit and vibrant development communities. It would be great to demonstrate their integration. It would be a mistake to adopt one as an official component, as I am afraid it would have a stifling effect on the development communities associated with those projects. Adopting one into Qt would give it an unfair advantage over the other.

That being said, here are the most important (in my personal opinion) features you would need to make Qt a great platform to build games on:

Issue Number One, dwarfing all others: Achieving a stable frame rate in the main loop, and in particular not having the main loop driven by a timer, but running “as fast as possible”, and also not stuttering as time is sliced for other reasons. Also the main loop not only should run as fast as possible, but should properly interact with the main Windows message pump so that CPU utilization does not inadvertently go to 100%, or switch the computer unnecessarily into high power drain/fans on max mode.

Issue Number Two: One should be able to write native rendering code as Ignacio suggests; including DirectX. This implies the availability of a DirectX implementation of QGraphicsView.

Issue Number Three: Access to user input devices such as Joysticks, 3d cursors, tablets, etc., in such a way that particular platform specific hardware, such as the X360 Controller for Windows can be utilized without difficulty. There should not be a generic uber generic joystick class, but a robust API that expresses fully the hardware the user paid good money for.

Issue Number Four: The functionality in QGraphicsView needs to be fully fleshed out to hit some big omissions such as editable text fields and so on that are currently missing or completely implemented.

n8dgr8 says:

Implementing / tightly integrating with Processing ( or OpenFrameworks ( would rock!

Haso Keric says:

How about Implementing fully why reinvent the wheel Ogre is Cross platform and is being used in commercial games already.

BogDan Vatra says:

IMHO adopting any existing projects will be a mistake.
For me Qt is like an orchestra, putting another player there will break his beautiful harmony.

Joshua Bury says:

I think easier integration with OGRE ( would be killer!

anono says:

I think the most logical step would be to integrate a physics engine in QGraphicsView.
It’s already a scenegraph and actually there is not THAT much to do, to integrate physical properties into QGraphicsItems.
This way, 2D games could be implemented on basis of QGV and also new interaction models could be done for UI innovations.

arg0 says:

Oh Yeah! Gamedev toolkit will be great and delicious addition into sweet and comfy Qt =)
P.S. I’m waiting for something like QtDDK, QtOSKernel or QtAI module =)

BeGo says:

QtGaming? Greats!!! it would be more interesting if it will be so easy to use even for beginners!

As a supporter to QtGaming, I prefer to have QtPeripheral first, used for handling external hardwares, from the household gadgets (mouse, keyboard, web cams, etc), somewhat tighter audiences (joystick, accelerometer, GPS, etc), and really tight audiences (stetoscopes, central on / off devices, smart cards, EKG, etc).

The third group is a half jokes, but the other two would be highly appreciated.

Sorry for off topics, how about integration with OpenCV? Remember old mobile games “Shoot That Mosquitos?” (Forgot the names, sorry).

Nettok says:

I would like to see easier integration with other systems like OGRE and ODE. Do not reinvent the wheel!

@Andreas 12 of us Gluon people people will be at the Munich DevDays, so if you’re going to be there… πŸ™‚

@Neoromountain Gluon’s maths are primarily done by the very advanced and super-fast maths library eigen – which also has nice things like quaternions and such πŸ™‚

@mh Personally i believe more in the Unity3D model… so that’s why Gluon Creator’s being designed more in that vein πŸ™‚

@arg0 Now, about AI… i and two others are building a behavior tree system for our MSc, is that what you’re thinking of? πŸ˜‰

NoName says:

Before you implement something for games, it would be better to implement some encryption like 3DES, BlowFish, AES and similar.
The next thing is not to include some “half” things. The XML implementation isn’t full implemented, only a “subset”.
The statemachine in Qt 4.6 is implemented “only subset”.
Why you don’t implement such things fully, why only in “subset”?

Philippe says:

Well, I must say I really don’t care about games! Games is a specialized domain and I doubt Qt could become a competitive solution in that domain.
I wish Qt could concentrate on highly tuned X-Platform modules usable by a wide range of applications… in the task database are waiting tons of suggestions about improvements of existing functionalities…

Edubart says:

I would love game API in Qt. These days I dropped using SDL and choose Qt with QGLWidget as replacement for coding crossplataform games. But I have to say that Qt in the current moment lacks APIs for gaming. Implementation in there area would be good. I also thinks that an integration with OGRE would be a nice shot. Ogre3D at the time is the best opensource 3d engine and is being used in commercial games already.

seva says:

If Qt could deploy on XBox360 and PS3 support for writing games would be useful.
IMHO Without supporting consoles 2D games don’t profitable.

parallaxe says:

I agree with NoName.

eskil says:

NoName, parallaxe: What are you missing in the state machine and XML implementations? In QtStatemachine there is nothing to “fully” implement, since it’s not based on an external specification. We’ve restricted the API to those features we thought made sense to support, as we did not want a bloated API.

Thor says:

Hate to dissent, but games in Qt strike me as completely the wrong direction. See the points of Scorp1us and Phillippe. Overall, I don’t think Qt is likely to become a contender as a gaming platform. Instead I would rather see it focus on things it does well or things that no one else is doing well.

Some examples? What about…

1. I still cannot believe it is true that QDateEdit QDateTimeEdit do not support null values. I found a request for this but it seems to have been open for years. How are people getting around this without writing their own version? Yes, of course you can, but that is exactly what you don’t want to spend time on and why people adopt products like Qt.

2. Reporting and charts have little direct support without going to an additional tool. That seems far more beneficial to users than starting up a game platform.

3. The area of computer to computer communication (client/server, peer-to-peer) has limited support. Tools for supporting things like RPC/Thrift/Etch/WebServices/gSoap/REST/etc. would be quite beneficial. As it is, building these things leads to far too much coding of the “plumbing”. Figure out a way to make bi-directional, secure/encrypted, synchronous/asynchronous, multi-transport (binary or http) computer to computer communication as easy as the internal signal/slot mechanism and I bet you would get massive, massive adoption of Qt.

Individual/small developers would probably enjoy playing with a game library in Qt and it would be kind of fun. But it seems unlikely that significant game development companies would consider Qt as an alternative. However, the items I mentioned are exactly the kinds of things that would drive adoption from application developers, both individual/small as well as larger groups/companies. It seems a matter of allocating time in a direction most likely to benefit and drive adoption of Qt.

Owen says:

As a game developer who uses Qt, I have this to say: don’t go implementing your own 3D engine. It’s not worth the effort – it would require devoting masses of resources to it to keep it up to date. Intergrating with a fixed 3D engine is probably a bad idea also, though perhaps offering a solution for intergratng with Ogre3D would be a good idea.

I’d say the same for physics; People here have been touting Bullet, Newton and ODE, but while open source, they are not the best; Many games would prefer to be using something like PhysX which is both heavily optimized and has hardware acceleration support (Also note that, IIRC, Bullet only does collision detection).

What would be ideal is the ability to render widgets into a scene somehow. Whether this is by rendering to a texture or rendering them directly (And the latter is preferable) is not important, but getting them in there is.

The other thing which would be great is support for joysticks and gamepads.

NoName says:

@eskil: For example in the qt statemachine there are transitions missing. Currently i could found the right point in the documentation. But the Qt Statemachine Compiler would be very nice to work more efficient.

In the XML and in the HTML implementation there is only a subset of the XSL and the CSS implemented. => A complete translation process from XML with XSL (1.0 or 2.0) to any other format isn’t possible.

The problem with CSS is, that if I want to load complex websites (or build them on my own) that using much CSS, such won’t work, because currently there isn’t a full implementation there.

Hi all,

Quoting the orignal message:
* Physics engine integration, perhaps in-house, 3rdparty, plugin based?
* Collision detection system (a more comprehensive one than what we have already)

From my perspective these two are QGraphicsView update.

Before upgrading to these neat things, I think you should bullet proof your QGraphicsScene/View a little more.
It’s currently not possible to develop a full application in a QGraphicsScene because of glitches like:

– You cannot add another QGraphicsView in a QGraphicsScene.
– The QWebView integration has a few glitches.
– QGraphicsLinearLayout doesn’t fully behave like a QBoxLayout.

The top priority for trolls on the graphics side should be : have a bulletproof graphics view as the backbone for next generation apps.
Thus capitalizing on kinetic and declarative ui.

That’s where I would put the manpower on.

What we want is rock solid apps, and less dev time with graphics view. That’s step 1.
Then we can start to think about 3D integrated apps.

If one wants a 3D engine right now he’ll buy one or link with Ogre.

Benjamin Arnaud.

Rob says:

I just started looking into Qt today as a GUI solution for my game engine, and it’s very attractive, potentially. Although I have my own full screen GUI system, I’d love to replace it with something like Qt (allowing my editor tools and in-game GUI to share a robust widget system would rock), but I haven’t seen an example or straight answer on whether or not it’s feasible. This post, however, seems to ask two questions, as β€˜games using Qt’, in my mind, is quite different than β€˜games written in Qt’.

I’d like to be able to use Qt as a GUI solution in my engine, as others have suggested, all I need is to be able to render to a texture at the least, and feed Qt the input. With that, I can do absolutely anything, on any platform, with any engine. Forgive my ignorance if this is already possible, but this is all I need.

Seems to me, games being able to use Qt with that type of platform independence would be the most desirable first step anyway.

Mr Bombastic says:

@ Benjamin Aurnad: Yes you can add QGraphicsView to QGraphicsScene. QGraphicsScene::addWidget(QWidget *widget) is your friend.

@ Mr Bombastic:

Let me rephrase : you cannot embed a widget in an embedded QGraphicsScene.

Last time I checked I got an assert : see

Per says:

I am working on porting the game Warzone2100 ( from SDL to Qt (, and the only thing I am struggling with is the documentation and/or support for overlaying Qt widgets on an OpenGL 3D scene. Getting the Qt widgets/painter to cooperate with an OpenGL render turned out to be rather non-trivial, and the documentation on the Qt side is sparse. On the other hand, running the whole game from within the Qt main loop turned out to be both easy and had no noticeable performance penalty.

While I agree with the comments that integrating a 3D scene or physics engine into Qt would be a bad idea, a good interface to OpenAL would be a awesome. A nice Qt wrapper for GLee or GLEW would be nice. The only thing I am missing so far in Qt Core is a pause() and continue() in QTime so that it could be used for tracking in-game time.

@Per: Congratulations, I remember playing Warzone 2100, great game, a shame Pumpkin studio is no more.
As for switching from SDL to Qt why did you make that move ?

Mr Bombastic says:

@Benjamin: Then I suggest you try again with a never release…because it works like a charm. This is also demonstrated in WolfenQt where it is possible to walk “into” another view.

Hakim says:

Hello i think that this feature will be great

Per says:

@Benjamin: It is still just an experimental port, not a done deal by any means. SDL stable is getting old and lacks a lot of the things Qt does, like fonts, SVG support and a widget system that can be extended for game use. Qt also does basic things like fullscreen and mouse cursors better than SDL. Another significant advantage is that Qt can replace many other dependencies, and lots of dependencies make open source projects hard to compile on non-linux platforms.

Anything you can give us to help us use OpenGL: Shaders, Overlays, Simple scene graph, 3d graphs. The list is long. I present Power Plants automated and animated in 3d. It’s much like a game. I’ve been using Qt since version 2 and began because of your support for OpenGL.

Rick Jafrate says:

am a member of the Adventure Game Studio community and would like to make you aware of AGS, a fantastic 2D game IDE. There are more than 1000 games, mostly freeware but also a number of commercial games as well, created with AGS.

AGS has been under continous development for 10 years with new versions being released approx 2-3 times per year. The IDE was previously implemented in C++ and is currently ported to (eeew!) but the runtime remains in C++ using Alegro graphics library. The IDE and Windows runtime is enhanced and maintained by the creator of AGS, CJ. There are Mac and Linux ports of the runtime that are community supported. It’s very difficult to keep these ports up to date because of the pace of development of the IDE and Windows runtime. Using Qt to implement the runtime would eliminate the need for ports or at least make it a trivial matter to create them.

Qt developers could also benefit by from the experience by knowing how well Qt can be applied to a real world example such as this and if there are any difficulties to be overcome or missing features. I am suggesting that AGS would make an ideal test case for 2D gaming because of it maturity, rapid development pace, vibrant community, and wealth of already produced games.

The only hitch is that CJ, the creator of AGS, had originally released AGS as open source only to have some punk attempt to appropriate it as his own work. Since then AGS has been a closed source freeware project which is, of course, not compatible with Qt Open Source Edition.

Andreas, you can at least have a look at our little community and what we are doing over there. If you find anything of interest perhaps have a quiet conversation with CJ about what you are planning for Qt with regard to gaming and ask what kinds of things would be on his wish list. Who knows you may even find a way of making Qt and AGS compatible. You can’t blame me for dreaming about it!

Anyway you asked for some interesting ideas about Qt and gaming and this was my best shot. Here are the links to the AGS website and forums. Bear in mind that I am just a voice in the crowd and have no authority to speak for the group.



salomon says:

I think this ius the only real thing that QT lacks.

The first thing to do would be to integrate in QT as a QGlWindget some main open source opengl 3D engine like OGRE, Irrlicht and G3D. Integrating physic engine directly into QT would only be for 2D games because those 3D engine all got plugins to integrate main physic engine (like ODE).
Some hack exist to integrate OGRE into QT as a QGlWidget but it is not very well done and not realy platform independant.
Beeing platform independant for such a feature would be very important cause a lot of library, depending on the platform, are doing what QT does. The main feature and argument of QT is being multi-platform.

A lot of work is already done to use QT in games. Here’s a list of what I think is lacking :
* Existing 3D engine integration.
* Existing physics engine integration.
* Game controlers access (Joysticks, rumble pads, etc)
* Full screen with ability to change screen resolution. Very mportant !

That’s all !

Rob says:

At the risk of sounding pretentious, I don’t understand why it’d be a good idea to add support for a particular rendering engine, if a goal is having the most platform independence, than adding more dependencies seems like a bad idea. Expose interfaces, and build rendering platforms (Ogre, Irrlicht, D3D, OpenGL, etc) on that, or let the community build whatever you don’t want to. Exposing interfaces for rendering the widgets allows not only the maximum level of platform support, but maximum expandability, since they can take advantage of what you have as well as whatever their particular platform/system has to offer when rendering.

CEGUI, for instance, does precisely this, and has support for all major systems I’ve seen mentioned here. While I don’t know Qt’s inner workings, and frankly little about it ATM, it seems if you are going to support another rendering engine, in a similar time-frame you could almost assuredly expose interfaces allowing Qt to support everything. If you build rendering interfaces, I’m quite certain most/all of the major renderer/engine vendors would be happy to write and support implementations, since it strengthens their engine(s) (also means it’s their job to maintain the platform specific implementation, so less issues there too). I’d love to support Qt in the same way, if given the chance :).

ritchy says:

Hi all. My 2 cents in this topic full of passion. Personnally, i admire Qt, but honestly it sound way too big to redevelop a new game engine, and I don’t think that’s the idea behind Andreas’s post. Indeed, it would be great to have official QOgre3D, QIrrlich, QG3D, QDirectX… that would take care of all the lousy and boring setup. A ready-to-use widget for these 3D engine directly from the designer πŸ™‚ (I did the Ogre designer widget “ready-to-use” for myself, but it was not that easy). On the sound layer and Inputs (like joysticks), a plateform independant stuff would be just great. For the physics, ODE is good, but looks like Bullet is the new trend (need to evaluate).

Mr.B says:

As another professional game developer who has made more than 30 games across desktop and console platforms, and currently making several commercial games using 4.5.2 for Mac and Windows, I would also like to weigh in (although I generally agree with Ola’s and Owen’s comments).

First off, Qt is an amazing piece of work. Targeting some APIs (and yes, there would need to be many, not just a “QtGaming” class) at very specific niche like game development will endanger it’s focus. Terrible idea even though in theory it would benefit me.

You should continue to focus on higher level features that will benefit everybody.

For example, the work that has already been done in the scene graph and ability to hardware accelerate it with a few lines of code is exactly the type of thing that benefits everybody. However, there is a lot of room for improvement in the performance of hardware accelerated scenes that mix in widgets. Continually improving that would allow application developers and game developers alike to build more smooth, fluid and interesting end-user experiences.

The one glaring thing needed in Qt though is much better audio support. Loading, saving, playing, mixing, etc. Basically look at your support for images as inspiration and you should have the same for audio.

Game developers have always been a resourceful bunch. Let us figure out how to integrate the physics, input, and scene management of our choice; it’s just not that hard to do and every game developer has their own idea of what is “best”.

Qt shines at the architecture of managing widgets across multiple platforms and providing a solid foundation and robust set of APIs to let developers re-skin and plumb their niche apps. Stay focused on fixing the bugs, optimizing where it makes sense and adding features that make Qt easier and faster at building apps (e.g. improve the debugger, creator, etc. too).

Andreas says:

Hi, all. Wow, thanks for all these comments. It looks like the topic is very popular indeed! And I like reading all the points that have come up. My job at this point is to try to wade through all the issues brought up and see what does and what doesn’t make sense for Qt.

I’m /personally/ convinced that for vertical features it’s best to let experts do what they do best (e.g., pls Qt guys, don’t try to write a physics or AI system!), and the points made about how Qt itself should keep its focus on the horizontal stuff that will benefit everyone is valid.

One issue with third party features is how available these modules are to our “target audience”. Can I just “get” gravity in my scene? But maybe we could rather focus on how others can make these special advanced features more easily available? Fex, here’s how to make your engine integrate best with Qt, here’s how you can ensure it can be deployed onto these platforms, these phones, and so on. Maybe even – here’s how you can convince the world that your component is stable enough to run preinstalled on a gazillion phones. πŸ˜‰

I’ll follow up with another post. Again, thanks for all the input!

stop says:


Qt has major issues with it’s antialiasing routines and we have spent thousands of dollars on commercial licences.

Why are you not spending time on this.. Read it…. You should all be ashamed of letting this out of the door.

I have been doing some further tests of the polyline drawing using the raster engine because my customers are complaining about line drawing performance.

I created a harness in Qt and tested in all versions from 4.4.1 right up to the 4.6.0 tech preview and observed the same results.

The conclusion is that there needs to be some serious profiling put on the antialiasing routines.

My harnesss used GDI+ as an example. I plotted long polylines using the raster engine and GDI+

Here is a typical benchmark.

Take a 1000 point Polyine with GDI+ and Qt’s DrawPolyLine routine with Antialiasing switched OFF.

GDI+ – 94 Milliseconds
Qt – 78 Milliseconds

All my tests clearly show that Qt is outperforming GDI+ in this area.

Same points but with Antialiasing switched ON

GDI – 172 milliseconds
Wait for it…
Qt – 10062 milliseconds

Thats a whopping 10 seconds. All tests where conducted without having to clip lines (I wanted that out of the equation because apparently there is a bug regarding long polylines and clipping)

Philippe says:

@stop, I saw the same problem last year (Qt 4.4.1) . Drawing individual lines rather than using drawPolyline “solves” the problem. The answer from the technical support was not very good “we
sacrifice performance for accuracy.”.

aviral75 says:

it will be great if QT Animation Framework can be developed so as to support particle effects ( if its not already supported) …to make things intuitive for game programmers there should be similar intuitive framework.

sroedal says:

@stop, the reason Qt is slow at rendering polylines is that it needs to correctly render the line joins (which you can specify using QPen’s join style). Thus, it can’t draw each line segment individually but needs to build a quite complex path consisting of the stroke of all the line segments, which is then quite costly to rasterize (the rasterizer is optimized for text-like paths with few overlapping segments). As Philippe points out using drawLines instead of drawPolyline will greatly improve the performance. Perhaps we should add a Qt::NoJoin value to the Qt::PenJoinStyle enum, to specify that you don’t care about joins and that the segments should be stroked individually. We’d still need to generate one big path when using opacity or a non-opaque pen however, as you don’t want the overlapping segments to be darker than the rest.

stop says:

I think I must be going Mad!!

Qt is FASTER than GDI at drawing polylines when ANTIALIASING is switched off.

The same line that took 78 milliseconds to render now takes 10 SECONDS when Antialiasing is switched on.

Can somebody explain the huge jump when the GDI+ engine only takes twice as long.

Or are you telling me that line joins rendering when Antialisasing is switched on accounts for this?!!!

stop says:


Look at the benchmarks I posted

No Qt is even faster than GDI+ at drawing polylines when they NOT Antialiased

This tells me that it has nothing to do with line joins or stroking.

Can somebody explain the jump from 74 milliseconds to 10 SECONDS when antialiasing is switched on?

In GDI+ it just doubles the time when antialiasing is on.

Adam Higerd says:

As far as physics is concerned, I’ve integrated Box2D with Qt before — two different ways, actually; one used QGraphicsView and one did direct QPainter rendering. Both worked quite well; it seems that they’re quite a nice match.

r4 software says:

Hi all…
I am playing games on pc and i like to know more about gaming…
I like this article because it’s provide lot’s of fun and knowledge…

info says:

But guys…

Qt – 78 Milliseconds not antialiased
Qt – 10000 Milliseconds antialiased

Surely that delta is way off the scale.

I am pretty sure this has nothing to do with line joins and I have already proved that
Qt is faster than GDI+ (Which is no slouch by the way in this department)

sroedal says:

@info, the line joins mean that the stroked polyline needs to be rendered as a whole, instead of rendering each line individually. Which in the case of a 1000-element polyline results in an outline path of 4000 elements, which then needs to be rasterized. Now, we use the Freetype rasterizer to do antialiased rasterizing, which is optimized for text rasterizing and performs best on paths without too many self-intersections. In this case the Freetype rasterizer is the bottleneck, spending 99 % of the run-time on generating spans to be blended. When disabling antialiasing we get ~60 ms per frame instead of ~10000 ms. It seems that the algorithmic complexity of antialiased rasterizing of paths is O(n^2) for complex paths with the Freetype rasterizer.

To solve this we could either replace the rasterizer, which is a pretty big job, or special case rendering of polylines with opaque pens when the pen width is small to render each line individually. The latter might lead to a slight degradation in quality at the line joins or at line intersections however. We’ve been reluctant to do this so far since the work-around is very simple, to use drawLines instead of drawPolyline, explicitly saying to Qt that you want the lines to be rendered individually.

info says:

Ok! Ok!
You have convinced me.

Now please tell your support department to stop sending me patches that
pretend to fix it. Where is Volker when you need him πŸ™

einsatz says:

I support this propostion 100%. Nishant, be serious pardner. I think the majority of active Qt developers use *nix platforms, so if any OS should come first, let it be a *nix platform…

wardred says:

For me it doesn’t make sense to make a Qt gaming library, but I’d like to see several things integrated into Qt if they aren’t already there that would help both QT and gaming:

Support for dynamically adding and removing any sort of controller. Gamepads for consoles is the most obvious thing, but once you have that, you should be able to add / remove keyboards, mice, etc.

Sound APIs.
Simplest sound api – just pipe sounds directly to the soundcard.
Something like the SDL Video api. Request stereo 44 khz, and fall back to whatever the system supports
Slightly more involved, do hardware mixing, if it’s supported. (In Linux, this could get messy.)
Fall back to software mixing, either Qt native or OS implemented.

Maybe 1 API for 3D sound using the platform’s native libraries.
And maybe 1 for MIDI
On this one if you implemented a software synth with loadable sounds if the hardware / driver didn’t support MIDI, that would be awesome.

Again referring to SDL
A good way to request a video mode and screen resolution, with applicable fallbacks.
Since I know Qt has OpenGL and OpenGL ES integration all ready, a 2D screen could actually paint to a 3D surface
without even really knowing about it. If it does know, include a flag to scale it up. (And maybe one to keep / break aspect ratio.)

Qt may have some/all of this all ready – I’m just starting to learn it, but I’m basically looking for API that could be consistently used to setup each of these things. If there isn’t a keyboard driver that turns off auto repeat and just listens for a keydown/keyup, that would be something to do. If there’s not a “quick paint” algorithm – at least outside of 3d hardware acceleration, then that would be something to look at too, but all of these things could be used regardless if it’s gaming or not.

I’d avoid too many hooks into higher level libraries, like a physics engine. The openGL bindings are good, but I don’t think I’d try to do much more than that.

My 2c as a beginning programmer with limited SDL experience.

Commenting closed.

Get started today with Qt Download now