QT + SDL for games?

I am willing to give a shot at making games, but I would like to use QT to help, using widgets and signals/slots to ease programming, and SDL for fast screen updates. How is it possible?
I would like some insight from people about what has been tried, and what works:

• Can I run QT on top of SDL?
• Can I run SDL as a Widget inside a QT app?
• If both are possible, which option delivers the best performance?
• How big is the performance hit when compared to a SDL only app?
• Which QT version is better for the task? QT3, QT4, QT/Embedded?

Thanks for the attention,

Brazilian Joe

From the way your question is written, it looks to me you are rather new to programming in general, and that you havn't wroked much (at all?) with SDL and/or Qt.
Yet you "decided" you want to use both.
I would suggest you first understand well what is each lib good for, and advantages and disadvatages and only then make you decision.
To your questions:

Quote:

---

Can I run QT on top of SDL?

---

Well you don't run 'on top' but 'link to'.
In this case you are asking if an SDL project can be linked to Qt.
Yes it can, the question is what for.(See the next point)

Quote:

---

Can I run SDL as a Widget inside a QT app?

---

You can link SDL to a Qt project, and it would make more sense then the previous point.
SDL is a very specific lowlevel multimedia lib, where as Qt (specially Qt4) is more general,high level with a more weight on GUI.

Quote:

---

If both are possible, which option delivers the best performance?

---

You should define 'preformance'.
But i think I unswered what you meant in the previous points

Quote:

---

# How big is the performance hit when compared to a SDL only app?
# Which QT version is better for the task? QT3, QT4, QT/Embedded?

---

These two questions (and the answers) depend on which kind of applications.
Some are better to be based on SDL (multimedia angines for examples) and some are better to be based on Qt. (high level GUI for example)
The right Qt version 'better for the task' or in deed the right lib to use depends on the kind and specification of the task, not on the libs.

Yes, you are right, I am not an experienced C/C++ programmer. that's why I posted on the Newbies section :)
Let me try to describe my rationale:

• SDL and qt are cross-platform
• SDL is good for doing fast 'graphic stuff' (yes, a crude definition, and also can do audio and more)
• QT has a wealth of widgets, and the signal/slot system, which makes GUI development easier

I would like to combine the strength of both systems, and use each one where it excels.

If I can use the SDL surface as the framebuffer to render the QT widgets, It would save a lot of time coding widgets, and would use a proven, high-profile system with a wealth of support, while still having direct access to the framebuffer to do fast animations. QT stuff could be used, for example, to do a status bar at the bottom of the game screen, while the majority of the window would be used for fast graphics.

On the other hand, If I can 'override' the complexity of the QT Widget system, which naturally has less graphics speed as a tradeoff for its power/features/flexibility, and have a SDL surface 'inside' a QT window (bypassing the lower QT graphics performance), I still have my direct screen access to do the graphics, and the power of QT.

Hopefully, this mix would allow me to use signals/slots to make the game mechanics talk to the GUI in an easy way, to further simplify the development.

Regardless of which way it's done (QT inside SDL or the other way round), it might incur on a performance penalty when compared to SDL alone, which might be acceptable or not.

SDL is already chosen for its virtues. Now i am looking for an easier way to do GUI stuff, so I am considering QT, if they can cooperate nicely.

The 'Right QT' is a matter of which one allows me to do it. Suppose QT/embedded can use SDL as a framebuffer, and the others cannot interact with SDL at all. In this hypothetical scenario the 'right choice' is QT/embedded. If all of them can be used one way or another, then I will do some sample coding and see which one delivers the best performance.

I am just looking for advice, because other people might have already walked this path, and hammered their head on the wall (and learned from their experience), and I don't want to blood-stain that wall even more, unless I need to. :)

Based on what you siad, I think that a Qt project linking to SDL would be a good solution.
I havent used SDL with Qt my self, but I know other people did.

Maybe you should use OpenGL for even faster performance...

Quote:

---

Originally Posted by wysota

Maybe you should use OpenGL for even faster performance...

---

...And out of the box compatibility with qt.
If you insist on using sdl the try this one http://www.libsdl.org/cvs/qtSDL.tar.gz for a hint ;) I'm not using sdl I must say but I remembered having downloaded this thingy some time ago and I just googled the filename and here you are :)

You did not write what kind of game you plan. If you want something with 3D you should learn OpenGL which you can use with SDL. AFAIK you can't render with Qt in a framebuffer. You simply have a special Qt Widget in which you can display your framebuffer.
Maybe you want something like http://libufo.sourceforge.net That should be easier to integrate, it even has a sample SDL application. Do you know the http://nehe.gamedev.net tutorials?

personally I would suggest Ogre 3D Engine

http://ogre3d.org/

Irrlicht is much better and the integration may not be that hard since an example demonstrate how to render inside a native window.

SDL was chosen because we don't wan't to lock out people with low-end machines, without 3D hardware. The game is 2D and uses an isometric tile-based view.
So the QT OpenGL makes use of hardware acceleration?

Yes, Qt Open GL is hardware accelerated. Otherwise you probably wouldn't use it ;)

Quote:

---

Originally Posted by Brazilian Joe

SDL was chosen because we don't wan't to lock out people with low-end machines, without 3D hardware. The game is 2D and uses an isometric tile-based view.
So the QT OpenGL makes use of hardware acceleration?

---

Hi,

when you mentioned SDL and isometric tiles, I immediatley think of Kyra. Its C++ built on top of SDL. It has specific code for isometric tiling.
http://www.grinninglizard.com/kyra/
I have a couple of unfinished games written in Kyra, and thought the API was easy, and the engine very powerful. But, if you're well into SDL already, this comment wont help :p
Kyra has some basic widgets built in, enough for a simple UI, but obviously its no Qt and not intended to be.

sorry if I'm getting off-topic, I love Qt for everything else, honest...

all the best,
barry

I'm making SDL-based game now. Some notes (my game is OpenGL-based)
I thought about making it run inside Gl widget in Qt app.. But then thought it would be slow.
Qt has nice classes to work with network, Qt has a great QString and other container classes. Maybe I'll use them linking to QtCore... But STL is not so bad, and parts of my app are from NVidia SDK that uses STL a lot.
The main code is OpenGL + NV_linear

Quote:

---

Originally Posted by Farcaller

I'm making SDL-based game now. Some notes (my game is OpenGL-based)
I thought about making it run inside Gl widget in Qt app.. But then thought it would be slow.

---

Could you explain how would it be slow? QGLWidget uses normal OpenGL context to render its contents, being wrapped into a Qt widget shouldn't make it slower.

Quote:

---

Originally Posted by wysota

Could you explain how would it be slow? QGLWidget uses normal OpenGL context to render its contents, being wrapped into a Qt widget shouldn't make it slower.

---

I mean that application based on Qt is slower than SDL-based application. AFAIK, Qt's event loopis more complex than event loop in SDL.

Take a look at its sources :rolleyes: It's soooooooo complex! :D

Quote:

---

Originally Posted by wysota

Take a look at its sources...

---

The best C++ tutor I've ever had ;)