3

I'm a relatively new developer, and I'm looking to learn C++. I've had experience coding in java, javascript, actionscript, and python, but I want something fast enough to do some high performance 2D and 3D games.

When I eventually learn the basics (control structures, classes, etc) I'd like to develop a 2D game. I've explored various libraries for 2D graphics (cairo, sdl, openframeworks, clutter) but clutter seemed to be the most optimised for accelerated graphics and vector drawing.

Would clutter be a good fit for a 2D game? I realise that it maintains its own scenegraph unlike other libraries, but I've developed a flash game in the past, so I should be used to that.

Are there any performance issues I should be aware of? Has anyone else had experience doing heavy graphics with clutter?

lukecameron
  • 33
  • 1
  • 5
  • 7
    Whatever graphics library you eventually choose, *forget everything you know* about Java. C++ is a wildly different language, and idioms that are normal in Java are sometimes dangerous in C++. – greyfade Aug 26 '10 at 09:41
  • I cannot emphasise @greyfade's comment enough. I am not even that experienced in Java, but it was pretty much my first language and I did get used to it. A year later, I am now turning to C++ and I have now multiple times gone very wrong trying to do things "the java way". – Stephen Aug 26 '10 at 09:43
  • haha well good thing I didn't learn too much java. My experience with high level languages (actionscript and python) might cause similar problems for me though. – lukecameron Aug 26 '10 at 09:53
  • I've used SDL extensively in my own portable C projects (I don't see any C bindings for Clutter, probably for obvious reasons) but Clutter does seem interesting if you're looking for *using* rather than *understanding* the core components of a game. I would suggest you move this question to the **gamedev** section on stackexchange. – gamen Aug 26 '10 at 10:05

3 Answers3

7

I've done a lot of embedded systems work using Clutter, and am now doing a desktop project with it. It would probably be great for a desktop-based 2D game, with certain caveats:

  1. Mainline development on the toolkit is very heavily Linux-oriented. I'm not sure how well the Windows, Mac, or iOS ("fruity") ports are maintained.
  2. Documentation is sparse, and afaik there are no books. (I'm thinking of writing one.)
  3. It's written in C, and natively exposes C-language bindings. While there are Clutter bindings for many languages including C++, you'll still need to understand the C-language bindings.
  4. It doesn't natively use C++ objects. Instead it uses the C-based GObject system for single-inheritance objects, and even if you're writing to it with the C++ bindings, you'll need to understand about GObject some, too.
  5. If you want to use it with threads, you have to use its threading system - not POSIX threads, or Boost threads, or anything else.
  6. It can really beat the tar out of a GPU, so if you're doing something fancy, frame rates can be mediocre on some of the low-end Intel chips used in cheap laptops and netbooks.

That said, you can do amazing things with it. I really enjoy working with it, and once you understand how to do it, mixing-and-matching with C++ is a lot of fun.

Also, there's a really rockin' open-source conference called GUADEC where the Clutter folks hang. If you were to show up there in July 2011 in Berlin with a really fun Clutter-based game, people would buy you lots of drinks.

Bob Murphy
  • 5,814
  • 2
  • 32
  • 35
1

I must admit I've never heard of Clutter before, probably because it's not a Windows library and the majority of games developers work on Windows platforms. Similarly, most game developers (even indie/hobbyist ones) are not considering Cairo, or Openframeworks either. More common by far would be the use of SDL, although that is not fully hardware accelerated and thus not a good choice for modern games. SFML is an alternative that is growing in popularity, but most game developers these days are probably rolling their own OpenGL rendering on top of something like SDL.

By the looks of it, Clutter might be a good choice, and it certainly seems fully-featured. But sometimes the problem with the larger frameworks is that they become a bit of a walled garden and it's hard to integrate extra bits that you might need - for example, I don't know how well the input might work.

The other problem with using a less well-known engine is that if you go to https://gamedev.stackexchange.com/ or http://www.gamedev.net and ask questions, the community won't be able to help as much since they are not familiar with the technology you're using. You have to balance the cost of that against the potential gains that come from using an unpopular but actually very competent library. (As well as the possibility that these other guys know something you don't...)

Community
  • 1
  • 1
Kylotan
  • 18,290
  • 7
  • 46
  • 74
  • Old answer, I know -- but what do you mean by "SDL...is not fully hardware accelerated"? I use SDL to get a window up and poll input, but after that it's all raw OpenGL. –  Feb 06 '14 at 18:35
  • 1
    @racarate: SDL, before version 2, did not implement its rendering in terms of OpenGL. It could draw sprites to the screen but not in the most efficient way. If you use OpenGL yourself directly, then you bypass this, but SDL did not, intrinsically, provide accelerated graphics rendering. As I understand it, this is no longer the case as of version 2.0. – Kylotan Feb 08 '14 at 18:03
0

Clutter is relatively new and there are not many applications that use it right now. Especially games. So you will have a hard time finding somebody who has experience with it for gaming purposes.

That said, clutter indeed has some interesting features that make it look compelling for the purpose, and I would even claim that for many types of gameplay the internal scene graph can even be an advantage to the game developer.

I would like to propose you another interesting option for 2D game graphics: Qt from Nokia.

While it is primarily a general-purpose GUI toolkit, it has nice proportions not every game developer would be aware of in first place. In fact, it has a fully-fledged OpenGL drawing backend which can be used to draw any widget, and to use any of Qt's canvas drawing operations.

Things go crazy as soon as you start to explicitely using a QGLWidget, which not only enforces GL drawing mode (which is not the default), but also allows you to mix your own GL drawings with Qt's drawing operations in the same context. You gain the possibility to not only use simple-to-use, high level drawing operations paired with a powerful event queue and efficient input handling; furthermore you keep the freedom to build-in more advanced, low level graphics in the future.

See this example. Note that you can mix native GL drawing freely with Qt's Painter functionality (if you take care of the GL matrix stack).

ypnos
  • 50,202
  • 14
  • 95
  • 141
  • 1
    QGraphicsView in Qt is well suited to plugging in to Box2D – McBeth Aug 26 '10 at 11:06
  • I'll seriously consider qt – I'd imagine that it is very mature after all of those years, and I hadn't realised its hardware rendering capabilities. – lukecameron Aug 26 '10 at 11:25