[Kde-games-devel] Reporting Progress

[Mauricio Piacentini]

Danny Allen wrote:
 > Right - looking over the text of the meeting summary, it seems to 
have a lot
 > of what I need ;)
 >
 > Of course, there are no cool screenshots there, so I may still be 
talking to
 > people ;D


Danny, I will wrap up the final summary in a couple of hours, already 
incorporated the corrections from Dmitry and Kleag. As for screenshots, 
you asked for them :)

http://www.tabuleiro.com/mauricio/kmahjongg_screens.tar.gz

This has 5 screenshots for the SVN version of KMahjongg. It shows angle 
switching using the stax layout. Angle switching is the ability to 
quickly cycle between 4 points of view of the board (NE,NW,SE,SW), 
mapped by default to the j and g keys. This is something missed on 
several Mahjongg solitaire implementation, but imo it is really 
necessary on some layouts so you can quickly check tiles that are 
obscured by other piles. This is specially required on deeper board 
layouts. And we will have some of them, as KMahjongg now accepts dynamic 
board sizes, where previously we were limited to 5 levels.

In order to implement angle switching I had to change drawing code yet 
again, separating the tile backs from the faces, and adding a sprite 
class that knows how to do the composition and layering quickly. 
Switching a view is very fast, as it requires no re-rendering of SVG 
content or pixmaps caches. You can checkout SVN and give it a try.

The version of KMahjongg currently in SVN is still a bit slow in the 
initial resizing, but this has to do with the large background being 
rendered from SVG without any caching or optimization yet. I plan to 
address this when customizing the background options.

As for next steps, there are still improvements needed to the board 
editor controls to accomodate the new dynamic board options, and a 
reorganization of menus and customization settings. Now that tileset 
format is defined I will also make KShisen use it, and write the 
guidelines for other tile authors. It currently uses an external XML 
file for sanity checking and versioning, and the names of the tile 
elements are specified in the SVG as element ids to optimize rendering 
(DRAGON_1, FLOWER_1, TILE_1_SEL, for example). My initial timing of 
rendering seems to confirm what Zach told me during aKademy, rendering a 
face using this approach from parsed SVG content takes more or less the 
same time as scaling a QPixmap. Final optimization will of course take 
place after features are frozen, and we hope to have a common approach 
(kpat, kreversi, kmahjongg, others) for initial rendering and caching of 
SVG data, something that is already being considered by myself, coolo 
and dmitry.

I believe this has more info then what you need, I will probably blog 
about this next week as well, after the commit-digest is published.

Regards,
Mauricio