Was looking into making a game with Qt and was wondering if QML has gotten to the point yet where it could be used as a serious tool on the desktop. Have seen some post from Qt stating that they will be transitioning most things to QML eventually, so this seems like it may be the way to go, at least according to Qt.
Edit: I realize that QML probably wouldn't be the best bet for a 3D game with heavy graphics. Was looking more for something that did mostly 2D stuff like a platformer type game.
Seen this http://labs.qt.nokia.com/2010/08/12/a-guide-to-writing-games-with-qml/. So its obviously possible to some extent. I have also seen some impressive games made solely with java script, which I believe is the base of QML. I was just curious as to what would be the best way to go with Qt at the moment since things have been changing lately...
It may depend on "how long" you want to wait before releasing your game.
The Trolls/Qt are re-doing its "graphics stack" right now: Rather than historic "every-widget-renders-itself" (which is the wrong paradigm for games and rich mobile apps), they are re-implementing to a single graphics stack that renders the WHOLE interface, where the "widgets" themselves are mere data-sets that feed into the rendering. In short, the goal is to make desktop/mobile applications with the exact same performance as the high-end games have done for decades (with their own graphics stack that looks nothing like the typical X/Xlib/Motif/Xvt/Win/MFC/Qt applications graphics stack). Further, the Qt5 plans (in planning/development now, they claim a release sometime next year) are reliant upon OpenGL for this graphics stack implementation.
After this work, the pipeline will be: Widgets==>QML==>(C++ Graphics Stack)==>Hardware. Currently (Qt 4 and previous) it is: QML==>Widgets==>(C++ Graphics Stack)==>Hardware.
You can google for various posts/discussions on this, or here's a long-ish presentation that talks about these efforts: http://qt.nokia.com/developer/learning/online/talks/developerdays2010/tech-talks/performance-do-graphics-the-right-way/
IMHO, QML makes more sense for games, since the interface components are "independent actors" (e.g., not tied to each other through layouts). That's also why QML makes so much more sense for mobile (where real estate is a premium), and for very flashy desktop apps (although it is still relatively young and unproven for that).
QML already has lots of rendering/animation options, but they are mostly a very rich 2D (but with which you could simulate 3D pretty well). The QML 3D is undergoing heavy revision right now, but the new stuff looks really good (and sits on OpenGL). So, if you want heavy 3D, it might be experimentation time for the moment, until you see the new Qt5 interfaces and can take advantage of the hardware acceleration (depending on how much 3D you need).
The performance specs I've seen from the new Qt5 stuff with the new graphics stack (in prototype development) are quite impressive, so much so that I've been thinking about writing some games in QML just to play with it. If this were twelve-months-from-now (or so, after the release of Qt5), I'd bet QML would be the best/easiest decision for games (because the components are independent actors, it's so simple to use, and I'd push all the game-specific heavy stuff into C++, which is really easy to do with QML on top).
QML is definitely a viable option for designing 2D games and can save you a lot of time and lines of code.
V-Play (v-play.net) is a cross platform 2D game engine based on Qt/QML with many useful V-Play QML game components for handling multiple display resolutions & aspect ratios, animations, particles, physics, multi-touch, gestures, path finding and more (API reference).
If you are curious about the games made with V-Play, here is a quick selection of them:
Squaby: a tower defense game
Chicken Outbreak: a platformer like Doodle Jump
Blockoban: puzzle game
Crazy Elephant: a game similar to Angry Birds
Snowball Mania: multiplayer action game
Blitzkopf: brain game
Remember that QML is only designed to lay out the UI. Fundamentally, it acts as a QGraphicsView with lots of utility functions (code in QML is at least three times shorter than the Qt/C++ equivalent, at least, that's how I felt it)
The core of the application is still handled by either javascript files (if things are not too complex) or C++/Qt files (if you want the full extent of Qt possibilities)
As Jeremy Salwen said, for a game that looks like a smartphone app game (big sprites that move with nice transitions, with simple logic behind it), then QML is more than sufficient.
But if you want something complex, then you will end up using in QML only QDeclarativeItem classes that you will have previously defined in C++. Not that useful.
Related
I need to program a game, it's a card game actually, and I must make it with graphic interface, but I don´t know about C++ graphic interface libraries.
Is there something for C++ similar to Python's Tkinter or Pygame (I don´t know if there are others).
If there are libs, are they suited for building a simple card game?
The most common cross-platform GUI toolkit is Qt, I'd go with that for any C++ GUI application. Especially easy on Linux, all distros have packages for it, but Windows has binary installers too for different compilers.
You can use Netbeans, but I'd really go with Qt Creator for Qt programming.
For a card game with Qt, QGraphicsView is probably easiest, if you want animated card movement etc. For a more static UI, QWidget based one would be very easy. For a modern visually rich UI, QML (but then GUI part is not C++) would work very well.
Achilles heel of Qt for game development is real-time game sound effects, but you can mix Windows-specific sound stuff easily if you do not care about cross platform stuff, and card games don't need much there anyway, if anything. Also, I think Qt5 may actually have improvements for sound, making pure Qt good enough for games.
If it is a game, you may consider SDL
Fun fact: pygame is backed by SDL.
BTW, if you want to have GUI controls in your game( http://www.tayloredge.com/utilities/vbapps/gui.GIF ) , you will need a GUI library. Otherwise, a game library, like SDL, is more suitable for you.
I would like to have a tool to debug 2D planar meshes. I would like to be able to display them and debug to be able to debug certain things.
Is there a widget (for any toolkit on Linux - QT, GTK+Cairo, ...) which would display the images, scroll them and zoom it. Is there any widget which would handle it (without need to implement zooming, scrolling etc. by hand)?
Side requirements:
Needs to work on CentOS 6
I need it for C++. Unfortunately changing the build system in my situation is harder then it sounds.
The Qt Graphics View is certainly a useful tool, it gives you scrolling, zooming, rotating easily. You probably want to learn the basics of Qt before. (and Qt is in C++).
Here's an off the wall suggestion.
This would be fairly easy to implement in a web browser. Web browser engines already have the base functionality for resizing and scrolling over images. You may need a little JavaScript to bind it together, of course.
So why not use WebKit? There are bindings for many of the leading toolkits (e.g. QWebView for Qt), so you could take your pick of which one you're most comfortable with.
Yes, it's overkill. But it's code you don't have to write, and time is money.
As a hobby, I've been working on remaking an old video game, and I want to avoid reinventing the wheel where possible. The game is heavily GUI-based, but the GUI needs to be customized in terms of look-and-feel, and also needs to work with 3D OpenGL rendering for a few game screens.
To give you an idea, here's a screenshot from the initial prototype:
There's a lot of animation used, and 3D also, but the GUI widgets behave much the same as in a standard desktop application.
Thus far, I've been using my own GUI library (it's not robust or complete, and I've been running into some problems).
I've been considering migrating to Qt given it's reputation and impressive features, and some of the nice screenshots on the Qt website. But I've never used Qt before, so I don't really have an idea of what it's capable of, or what kind of time investment would be required to learn it. (Note I've used FLTK).
My question is: would it be possible / practical to use Qt in this situation?
UPDATE: After mocking up some game screens in Qt, I've decided not to use it. While it supports many of the features I need out-of-the-box (particularly through Style Sheets), I need to support custom bitmap-based pre-rendered fonts (I can't convert/replace them). And I can't subclass QFont, or reimplement it without it breaking in future Qt releases. That said, I was extremely impressed with Qt (both in its ease of use, and good documentation). I will be borrowing some of its features for my own engine. Thank you to all who provided input.
It's hard to know everything your game needs to do based on a screenshot; however, I will echo the sentiments of other posters here and provide a couple of avenues for you to look at.
One, is that you might want to consider QtQuick over the GraphicsView Framework, but this REALLY depends on what you need to do. I just want to throw it out there as an alternative so you don't miss it. This tutorial uses QtQuick to put together a really slick looking connect four style game. This may be more simplistic than what you want to go for, but then again, maybe it isn't, it depends on what you need to do.
Second, before writing custom paint events for all of your buttons, I would consider using Qt Style Sheets and style your widgets in a CSS like syntax. This will allow you to change the look and feel of your GUI in a very flexible way really quickly. Based on your screenshot, I think you can get what you want out of style sheets much faster than subclassing and rolling your own setup. But once again, it's hard to know based on one screenshot. Here's an example of a dark and orange GUI that was implemented using only Qt Style Sheets. The border-radius property of QPushButton's style sheet would give you the rounded buttons (ref).
The simple answer has been given above but to throw some more thoughts in: yes it's possible, you probably won't need to fight against Qt too much. For the most part the recommended advice for going to heavily customised widgets like that is subclass and implemented the paint event yourself.
You can then use a load of basic drawing primitives to get the basic shapes for the elements and expand from there. There's actually a couple of questions on here with really good resources about how to do it.
I am exploring a possibility to write a kind of a notebook analogue that would reproduce the look and feel of using a traditional notebook, but with the added benefit of customizing the page in ways you can't do on paper - ask the program to lay ruled paper here, grid paper there, paste an image, insert a recording from the built-in camera, try to do handwriting recognition on the tablet input, insert some latex for neat formulas and so on. I'm pretty interested in developing it just to see if writing notes on computer can come anywhere close to the comfort plain paper + pencil offer (hard to do IMO) and can always turn it in as a university C++ project, so double gain there.
Coming from the type of project there are certain requirements for the user interface:
the user will be able to zoom, move and rotate the notebook as he wishes and I think it's pretty sensible delegate it to OpenGL, so the prospective GUI needs to work well with OGL (preferably being rendered in it)
the interface should be navigable with as little of keyboard input as user wishes (incorporating some sort of gestures maybe) up to limiting the keyboard keys as modifiers to the pen movements and taps; this includes tablet and possible multitouch support
the interface should keep out of the way where not needed and come up where needed and be easily layerable
the notebook sheet itself will be a container for objects representing the notebook blurbs, so it would be nice if the GUI would be able to overlay some frames over the exact parts of the OpenGL-drawn sheet to signify what can be done with given part (like moving, rotating, deleting, copying, editing etc.) and it's extents
In terms of interface it's probably going to end up similar to Alias' Sketch Book Pro:
picture.
As far as toolkits go I'm considering Qt and nui, but I'm not really aware how well would they match up the requirements and how well would they handle such an application.
As far as I know you can somehow coerce Qt into doing widget drawing with OpenGL, but on the other hand I heard voices it's slot-signal framework isn't exactly optimal and requires it's own preprocessor and I don't know how hard would be to do all the custom widgets I would need (say color-wheel, ruler, blurb frames, blurb selection, tablet-targeted pop-up menu etc.) in the constraints of Qt. Also quite a few Qt programs I've had on my machine seemed really sluggish, but it may be attributed to me having old PC or programmers using Qt suboptimally rather to the framework itself.
As for nui (http://www.libnui.net/) I know it's also cross-platform and all of the basic things you would require of a GUI toolkit and what is the biggest plus it is OpenGL-enabled from the start, but I don't know how it is with custom widgets and other facets and it certainly has smaller userbase and less elaborate documentation than Qt.
The question goes as this:
Does any of these toolkits fulfill (preferably all of) the requirements or there is a well fitting toolkit I haven't come across or maybe I should just roll up my sleeves, get SFML (or maybe Clutter would be more suited to this?) and something like FastDelegates or libsigc++ and program the GUI framework from the ground up myself?
I would be very glad if anyone had experience with a similar GUI project and can offer some comments on how well these toolkits hold up or is it worthwhile to pursue own GUI toolkit in this case.
Sorry for longwindedness, duh.
Have you tried FLTK? It is made with 3D graphics programming in mind and has interfaces to OpenGL. I wrote some FLTK->Scheme bindings and found the API to be real fun to work with.
OpenGL font support is terrible, in my experience. It sounds like you're going to have to develop all your own custom widgets anyway so don't even bother with a toolkit. You'll spend more time learning the toolkit, trying to figure out how to get that toolkit to work with OpenGL, and and trying to figure out how to make your special widgets in that toolkit than you will just rolling your own. I wouldn't give this advice in just any situation but it sounds like your application and your widget set is going to be very unique. Make a superclass for all widgets, define a draw method, even handler methods, etc., for override, and you've already done most of what those frameworks would do for you.
Also I'm sure you know this but this is an enormous project so you should initially narrow it down to a few simple objectives for a first iteration.
So, I'm going to develop a Pac-Man clone with Qt. The problem is that I do not really know where to start.
I quickly take a look at the documentation and some demo. I also downloaded some game sources on qt-apps.org. And it seems that there is a lot of ways to develop a game with Qt!
In your experience, which part of Qt should I consider to develop a Pac-Mac clone ?
The Animation Framework
The Graphics View Framework
The Paint System
Qt Declarative
Any help would be appreciated.
I think that QGraphicsView framework is the best way. Create a QGraphicsScene, some QGraphicsItems for the elements of the game. You have collision detection for free.
Most of KDE games are based on the QGraphicsView framework. It is a good fit for simple game development.
I'm currently working on a project providing gaming-specific Qt Quick Components for cross-platform game development, might be of interest: http://v-play.net :)
At the very minimum you will want to look at QGLWidget. You can get an OpenGL program up in a few minutes by deriving from QGLWidget, it will create the window, context, handle mouse and keyboard input, etc. Create a QTimer to trigger updateGL() every 10-15 ms or so and your good to go. I think there is a demo somewhere for setting this up, but it has been awhile since I saw it.
If you want to embed widgets into the window, I would look at QGraphicsView. There is a demo of this called boxes. Just beware the demo is a tad hard to learn from as several classes are thrown into the same file and it might take a few moments of tracing to figure out where the flow is.
Since you are doing a 2d game, you might want to look at using QPainter on top of OpenGL. This allows you to draw primitives easily instead of doing them with OpenGL calls. I never could get this to stop flickering in fullscreen though.
There's a book about game development in Qt here, it's a bit old, but it might give you some ideas. But IMHO, Qt is widget based and is a bit slow for a game, you might consider using SDL or OpenGL.
I'm developing a simulation of rigid bodies with Qt and OpenGL using the PhysX API from Nvidia. If you want to see this approach, look at my project at github: http://github.com/lucassimao/Simulacao-Estereologica
Well, one place to look could be the Gluon game development framework, which is currently under development. It depends on what you're really aiming for with your PacMan clone, but Gluon may well be what you're after: https://github.com/KDE/gluon
If anyone else is interested in learning how to make GAMES using C++ and Qt, have a look at my YouTube tutorial series. It explains the graphics view framework through a series of videos which build upon a single game that we start in tutorial 1.
C++ Qt Game Tutorial 8 - Adding Graphics
If you are not comfortable with Qt yet, then I REALLY loved VoidRealm's Qt tutorial series, also on youtube (C++ Qt 1 - Introduction to QT programming).
A good start would be:
Qt Examples And Tutorials
Perhaps if you need to cheat you may want to look here
xpacman.tar.gz