[Kde-games-devel] KMahjongg (almost) using SVG theme

[Albert Astals Cid]

A Dimarts 22 Agost 2006 00:56, Mauricio Piacentini va escriure:
> Hi, guys. It took more time than what I have predicted, thanks to
> several incompatibilities while trying to get my vectorial data into
> Inkscape, and exporting it in a way that could be rendered cleanly by Qt
> SVG. We had to basically redo everything... But I am almost done with
> the art and code to make KMahjongg use SVG to render the tileset and
> background. See a preliminar screenshot at
>
> http://www.tabuleiro.com/mauricio/kmahjongg_svg.png

It looks gorgeous!!!

> There are some issues that I need to solve regarding tile spacing (they
> need to be closer) and shadows, so this is not final yet. The old
> version (for comparison) uses a fixed pixmap tile size:
>
> http://www.tabuleiro.com/mauricio/kmahjongg_old.png
>
> I am happy with the results so far, and I hope I will be able to merge
> it into SVN in a couple of days. But I need some feedback from you guys,
> and Alberto specially, as he is listed as the current maintainer (and
> bug owner!)

Nitpicking (Albert)

Well, as i said it looks wonderful, and now, would you like to become current 
mantainer and bug owner?

I'm the current one because noone else was and i'm only doing very low level 
mainteinership (that is fixing a few easy bugs) so you seem like a good 
candidate for a new kmahjongg maintainer to me.

> The following bug (wish actually) will be addressed by the new code, as
> I am planning to make the window resizable, and scale the background and
> tiles accordingly:
>
> http://bugs.kde.org/show_bug.cgi?id=121960
>
> However, there is a decision to be made. Would we still support the
> older tilesets, unmodified? Supporting the backgrounds is easy, we could
> still accept any png, jpg or svg file, with the option to tile or scale
> accordingly. The screenshot above shows a SVG background, btw. Custom
> layouts will also still be supported without modification.
>
> But there are some issues supporting the older tileset files as they
> are, specially because they assume a fixed tile size. They also do not
> support resizing easily, since the code uses a fixed color for
> transparency, and as a consequence the existing tileset graphics do not
> use antialias. We can of course compose first and then scale. Tiles will
> look crappy, however. The code that generates shadows is very good, but
> it is not very flexible, so it is difficult to adapt it to use tiles
> with round corners for example, or for tiles of different proportions.
>
> I was hoping to clean up this older code, and start with a more flexible
> design, one that accepts png and svg, automatically using the alpha
> channel for transparency and shadows. I also plan to add spacing, aspect
> ratio and shadow information in an external .tileset file, where the
> name of the .svg or .png data will be listed along with geometry
> information. This would let the artist have more control over the shape
> of tiles and shadows. The code will also be easier to maintain, since we
> will switch to use QPainter for all blitting and will no longer be
> drawing shadows by setting pixel data in pixmap caches.
>
> Of course, I would add code to detect if the user is trying to load an
> older tileset (specially in upgrade scenarios), and deal with it
> gracefully. But I would like your OK to go ahead with this plan before I
> rewrite the drawing code.

I would say the HUGE gain we get from having SVG tilesets is good enough for 
the lose we get, but if you want i (or you) can blog about it and see what 
people says, also contact Richard Lohman (mail on the web page) maintainer of 
http://games.kde.org/kmahjongg/index.html that will be happy to get news from 
you :-)

> Also, there is an issue that can not be solved unless we ditch the
> current method and adopt a more flexible scheme for loading themes,
> tilesets and backgrounds. So this is one more reason to change it.
> Please read the bug at
>
> http://bugs.kde.org/show_bug.cgi?id=129469
>
> I don't know if it is possible to solve this issue completely, but my
> plan was to ship only a default (new) tileset with the new revision, and
> at the same time implement the KNewStuff framework. I do not know much
> about it yet, but it apparently supports localization of resources (or
> should!) 

Yes, it supports localization but was not very good AFAIK, maybe Josef has 
fixed it, you can contact him at spillner AT kde DOT org  (Josef is knewstuff 
creator and mantainer) (or was :-D)

> Then I plan to get the current legacy tileset art (pirates and 
> default) and maybe wrap them as KNewStuff packages, so people could
> still get them if they want to, and if they do not mind the scaling
> artifacts.
>
> How does this plan sound?

Good.

> BTW, I plan to give the same treatment to Shisen-sho next week,
> converting it to use this new SVG tileset and background. Maybe I can
> add custom tileset support to it as well in the future, with KNewStuff,
> and put the resources in a shared location for both games. Implementing
> KNewStuff seems like a good task for Akademy, as I would have the help
> of kdelib guys if needed.

Go Go Go!

Albert

>
> Regards,
> Mauricio
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel