PDA

View Full Version : QT + SDL for games?



Brazilian Joe
18th January 2006, 13:36
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

high_flyer
18th January 2006, 15:55
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:

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)

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.

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

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

Brazilian Joe
18th January 2006, 19:48
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. :)

high_flyer
18th January 2006, 22:20
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.

wysota
18th January 2006, 22:21
Maybe you should use OpenGL for even faster performance...

yop
18th January 2006, 22:56
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 :)

Codepoet
18th January 2006, 23:02
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?

ball
19th January 2006, 06:58
personally I would suggest Ogre 3D Engine

http://ogre3d.org/

fullmetalcoder
19th January 2006, 09:48
Irrlicht is much better and the integration may not be that hard since an example demonstrate how to render inside a native window.

Brazilian Joe
19th January 2006, 13:45
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?

Codepoet
19th January 2006, 17:35
Yes, Qt Open GL is hardware accelerated. Otherwise you probably wouldn't use it ;)

barryrs
20th January 2006, 12:35
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

Farcaller
23rd January 2006, 14:35
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

wysota
23rd January 2006, 18:55
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.

Farcaller
23rd January 2006, 20:03
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.

wysota
23rd January 2006, 20:31
Take a look at its sources :rolleyes: It's soooooooo complex! :D

yop
23rd January 2006, 20:34
Take a look at its sources...The best C++ tutor I've ever had ;)