KDE Games: Towards an “Active” interface

The fact that KDiamond is included by default in Plasma Active’s default set of “Favorite applications” (among rekonq-active, calligra-active, and friends) finally made me hack a bit on kdegames stuff again. The main problem I see with KDiamond on a mobile form factor is that menubar and toolbar waste quite some vertical space. Also, the menubar is awful to use on a touchscreen; the toolbar is much better in this regard.

Can we combine these observations into an interface that saves space, yet is as approachable as a simple toolbar? We can.

In the back is the normal menubar/toolbar chrome. In the front is my first draft of an “Active” version of it. The menus “Game” and “Move” are completely gone, all contained actions are now on this first level of the toolbar. The “Settings” and “Help” menus have turned into toolbar buttons. Upon pressing one of these, the toolbar descends into that subcategory:

After selecting something from a subcategory, the toolbar automatically returns to the default category. For example, if you click on “Settings”, then on “Configure KDiamond”, the theme selection dialog comes up. When you’re done with that, you come back to the main window and find the default toolbar with the relevant New/Pause/Hint actions again.

What do you think? A first step in a good direction? Something you would even want on the desktop? Or just plain awful? Please let me know. BTW the source is available on ReviewBoard.

P.S. To get that straight: This is only for games with a small set of menu actions (about 28 of 40 KDE games, according to my counting). Apps like KGoldRunner or KTuberling just don’t fit the idea behind this proposal and will therefore not be affected.

P.P.S. I’m aware that vertical space is still wasted. I’m going to experiment with moving the toolbar to the side for displays which are wider than tall.

Visual tour through kdegames 4.6 Beta 1

Long time no see! I’ve actually been cut off from KDE development lately because the 4.6 Beta 1 update broke KMail temporarily, which is a blessing in disguise because it gives me time to focus on my upcoming exams.

Anyway, the KDE Applications 4.6 Beta 1 release is out (is that correct promo-speak?). Time to take a look at what is hot and new in kdegames 4.6 Beta 1. And the hottest way to do that is a visual tour:

Palapeli has received quite some polish. Johannes Löhnert has contributed a new set of slicers, which is now known as the Palapeli Slicer Collection. The screenshot shows the Cairo slicer which produces pentagonal pieces. Other shapes (both usual and odd) are available, and configurable to your liking.

To honor the addition of this big set of slicers, the puzzle creation dialog has been revamped. Create your own jigsaw puzzles in three easy steps (image file, slicer, parameters)! The screenshot shows step 1 (bottom right) and step 2 (bottom left).

Furthermore, Johannes has sent in a patch that creates a bevel effect on the pieces. As can be seen on the screenshot, they appear three-dimensional now.

As a regular reader of my blog, you probably know that Kolf has received some love lately: I have mostly worked on cleaning up the internals and making the code readable, so the only visible result is the new on-canvas controls in the editor (see top right of the course, where I have selected an elliptic slope below the cup). Saving edited courses is a bit broken in Beta 1 (and probably also Beta 2), I hope to sort that out before the final release.

The other big new feature in Kolf is that balls don’t tunnel through walls anymore, though that’s hard to visualize in a screenshot. But I can tell you that it’s a great feeling to close an eight-year-old bug.

No, the new feature in KDiamond is not an embedded KSysGuard view. I’m using KSysGuard to visualize the important change in here: KDiamond has reduced its memory usage with the new KGameRenderer framework. I’ve written about KGameRenderer before: Long story short, it introduces multiple levels of caching to speed up rendering of vector graphics theme elements. This was previously done in each game by itself; now it’s done once right by the KGameRenderer classes in the libkdegames library.

At this place, I’d like to thank all the volunteers that helped us to port a total of 13 games to KGameRenderer. This also includes:

Yes, it’s Klickety! We lost it in the KDE 4 transition, but now it’s back. As a fun fact, KSame has been removed: It is now “simulated” by Klickety through a “compatibility mode”, much like KSnake lives inside KTron.

Continuing on the track of new applications, Knights has just become the first game to be hosted on Git. It is stable, but has not yet had an official release because we still need to figure out how to release stuff from Git. However, some distros have packaged it already (e.g. openSUSE in the KDE:Unstable:Playground repository).

There are even more changes which I don’t remember now, or which I can’t write about because I don’t know the apps. The latter includes most notably Kajongg: It’s actually sad that Wolfgang Rohdewald, the developer of Kajongg, is not blogging on the planet. I’m regularly seeing dozens of commits from him, he’s active like the whole rest of the kdegames team combined, but no buzz is being generated about Kajongg, which makes me sad.

Also from the “interesting-changes-that-I-cannot-talk-about” dept.: KGoldRunner has gained a new input mode, and can now save the selected input mode (as far as the 4.6 feature plan tells me).

This concludes my visual tour through kdegames 4.6 Beta 1. More changes have happened under the hood, e.g. Granatier uses <a href="http://community.kde.org/User:Majewsky/Project_TagaroTagaroAudio for sound output, thereby replacing an optional dependency on GluonAudio by direct OpenAL+libsndfile usage.

Code from Project Tagaro is also being used by Kolf for its rendering. These uses all copy the relevant source code into their own source trees because libtagaro is nowhere near production-ready. I hope to get libtagaro into the state of a private library inside kdegames for the 4.7 release, to make kdegames even more resource-efficient, to make them fit for mobile form factors, and to make it easier to maintain them. Help is always appreciated.

KGameRenderer: Less is more

Last month, I wrote about KGameRenderer, the integrated rendering framework for 2D games which I’m creating for the 4.6 release* of kdegames. If you followed the relevant development mailing lists (kde-core-devel, kde-games-devel) lately, you know that the first version is mostly done and in the review phase.

The productive atmosphere here in Tampere was the right opportunity for some benchmarking. I already knew from my experience that KGameRenderer-enabled games are faster, both in startup time and animation performance, than their counterparts using their own possibly suboptimal rendering code.

There’s another question, though: Does a sophisticated, multi-layered image cache use more memory than the more primitive solution? The short answer: No, it uses less. The long answer: I have measured memory usage of the 4.5 KDiamond and the KGameRenderer-powered KDiamond in different scenarios (with cache, without cache etc.) and found that the KGameRenderer-powered version consistently uses ~1MB less memory. That may not sound much, but it’s already over 7%** of KDiamond’s non-shared memory.

To put these numbers into perspective for our fellow developers: The KGameRenderer port of KDiamond actually uses a more complex item graph on its graphics scene (because diamonds are KGameRenderedItems now, which consist of two items internally), so the lower memory consumption comes mostly from clever caching strategies (e.g. by automatically discarding pixmaps generated by intermediate resize events which occur very often during a KXmlGuiWindow initialization). Another optimization which I expected to show up in this measurement is the delayed SVG loading. In fact, KGameRenderer does not load the SVG file at all if the cache is current and contains all needed pixmaps. However, there is no measureable difference in the lower memory consumption in the cold (without disk cache) and the warm start (with disk cache). This could possibly be different for games with complex SVG themes.

All in all, assuming that I have time to port enough games*** to KGameRenderer, you can expect 4.6 to be the least resource-intensive release of the kdegames 4.x series.

* Yes, I’m not talking about the 4.5 release, that one is basically over for me (modulo maintenance fixes). I’m already deep inside the 4.6 cycle and have started merging my feature branches, with KGameRenderer merge into trunk coming next week, in order to get as much testing as possible before the release.
** The numbers have been measured with KSysGuard and xrestop, and are just there to give you an idea of the dimensions. You probably know that there is no absolutely reliable way to measure memory usage of an application.
*** At the moment, there are only ports of KDiamond and KSame.

KGameRenderer: Caching on multiple levels

If you read Planet KDE regularly over the course of the last weeks, you know that kdelibs 4.5 comes with the shiny new KSharedDataCache. Michael Pyne explained its purpose and design in a nice series of blog posts.

With KDE SC 4.5 coming onto my disk (at least the second Beta), it’s the right time to take advantage of this KSharedDataCache and its sibling KImageCache. Like many other applications in the kdegames module, KDiamond (your favorite clone of a trade-marked game about assembling rows of jewels) uses the predecessor of KImageCache, which is called KPixmapCache.

KPixmapCache is actually working quite well, but there may occur problems when multiple instances of KDiamond are running at the same time. I know that such bugreports are going to appear somewhen (regardless of the abstruseness of this configuration in the context of most of our games), so it’s better to fix these problems by moving to KImageCache. And while we’re at it, this is the right opportunity to rewrite the whole rendering code in KDiamond.

What’s the problem after all? Why does a game as simple as KDiamond need a complicated rendering infrastructure? The problem is that its fancy themes are vector graphics (in the SVG format). Simply speaking, vector graphics files are not an image of themselves (i.e. a bunch of pixels, like the bitmap graphics files which your digicam generates), but a bunch of painting instructions like “create a line from here to there”, “draw it with a thick black pen”, “fill this rect with that gradient” which can be used to create the image in question.

The advantage of vector graphics is that they can be used at different screen resolutions. But there is a clear disadvantage: Vector graphics are complicated to draw. In the simplest case , a bitmap can be drawn by simply putting the bitmap into the video memory at the right position (“blitting”), while drawing even simple vector graphics involve dozens to hundreds of rendering operations.

Therefore, most KDE games use some form of pixmap caching: The rendering operations are performed off-screen on a pixmap, which is then put on the screen. This pixmap can be reused, so some games save the pixmaps on the disk using the KPixmapCache (or its successor KImageCache).

In the above picture, we see the situation with a KImageCache. The single game elements (diamonds in this case) need to be rendered from the SVG graphics file only once. Any following requests will reuse the cached images. But there is another problem: Using the KImageCache introduces a non-negligible runtime overhead which slows down access to the cached pixmap (i.e. the right arrows, which, as you see, are plenty).

I have had a good experience lately with using a second cache inside the application, which is optimised towards serving pixmaps as fast as possible. With this change, KDiamond’s animations are suddenly fluid, especially the explosions when diamonds are removed. These animations consist of multiple images (“frames”) which are shown in fast succession, so there is a high traffic on the cache. While the application is running, these images become available in the high-availability cache and can be served quick enough.

With this experience, I am currently building new classes for our libkdegames: KGameRenderer implements theme management (a level higher than the current KGameTheme class), simple management for animated sprites (as in: series of frame images), and the caching strategy outlined above. It is accompanied by a helper class KGameRenderedItem. This is basically a QGraphicsPixmapItem which automatically reacts to theme changes and resizing by fetching suitable pixmaps from the cache.

A funny feature of KGameRenderer has been copied from KGoldRunner’s renderer (KGrTheme): If all pixmaps are cached already, the SVG file is not loaded at all. The impact of this optimization is not that high for KDiamond, but it certainly is for applications with many graphical elements, or for complicated themes.

For testing, I have ported KDiamond to use KGameRenderer and KGameRenderedItem. The stability is already suspiciously high. Compared to the previous KDiamond versions, graphical performance is much better during the game, but the startup is slower. When these problems are resolved, I hope to get these classes into libkdegames for KDE SC 4.6. If there is time left, I’ll probably port more of our games to KGameRenderer, and look into multi-threaded rendering. (You may also look forward to nicer animations in the next KDiamond, stay tuned!)

Please help with testing! It’s easy!

If you’re running a current KDE SC 4.4 snapshot (all packages and self-compiled variants are okay), please compile/install KDiamond from kdegames. Start KDiamond, pause the game after some seconds, and unpause it after some seconds.

Please write back (either as a comment to this blog entry, or as a mail to me) what you observe: Normally, pausing should hide all diamonds and display a popup in the top left corner of the board, and after unpausing, you can continue to play the game as usual. But on some systems, the popup will get stuck in the middle of the appearing animation, stay there after unpausing, and the game will not be playable even after the unpausing.

Please also write back if everything works fine on your system, and in any case, include the following information in your report:
1. Which distribution do you run? Which version?
2. If you compiled your Qt and KDE from sources, which branch of Qt did you use, and when did you update KDE the last time?
3. If you installed your Qt and KDE from packages, which repositories did you use?

Update: Thanks to anyone who sent information. I’ve found the root cause of the issue: KStatefulBrush. Silly as it sounds, but usage of KStatefulBrush results in an infinite loop. I’m still puzzled why this problem appeared only for me. The problem is actually a bug in Qt.

Rounding errors

A long-standing problem in KDiamond was that the lower and right border were thinner than the upper and left one. I finally had a deeper look into this with a special debug theme (big rectangles instead of partly transparent SVG masterpieces) and found that this issue was caused by rounding errors. When converting from a floating-point precision number to an integer numer, the digits after the decimal point are usually cut off. In my case this let all diamonds move to the lower right. The bug is now partially fixed, the rest is virtually invisible.

Meanwhile, a friend of mine has started his first KDE application. Palapeli (located in playground/games) is a jigsaw puzzle game. Unlike the normal jigsaw implementations, you do not have to move the pieces from a list onto a fixed board, but can move the parts freely. We will release a first preview version once we have loading and saving of puzzles, and a proper “New puzzle” dialog. Right now, there are only some command line arguments, so if you want to try Palapeli, make sure to pass something in the “–image” argument. For any further questions, `palapeli –help` is your friend.