[Kde-games-devel] KGameRenderer Porting Experience

[Parker Coates]

On Tue, Aug 3, 2010 at 04:01, Stefan Majewsky wrote:
> On Monday 02 August 2010 18:22:01 Aaron J. Seigo wrote:
>> text color is a very common thing in themes. not having that in the
>> base theme class sounds a bit broken, tbh. i wonder if the other such items
>> that are cached in your implementation are similarly common theme related
>> items that would, if moved into the base theme class, be used by other
>> games.
>
> KGameRenderer ATM basically forwards the methods exposed by
> QSvgRenderer (render -> spritePixmap, boundsOnElement -> boundsOnSprite
> etc.). I do not know how to extract any specific colors, fonts or such from
> the theme.

Killbots and KPat both store colours in the SVG as a solid coloured
rectangle. The element is then rendered to a 3x3 pixmap and the centre
pixels colour is extracted. (The centre pixel of a 3x3 pixmap is used
instead of just a 1x1 pixmap to avoid any possible edge effects during
the rendering.) While I don't think this is the world's most elegant
solution, in practice it works really well. The artists can change and
preview colours directly in Inkscape (which they tell me they much
prefer to editing .desktop files).

If there where some consensus across games about this system, then a
QColor colorOfElement() method could be added to KGameRenderer. This
would have the advantage of caching the QColor directly instead of the
3x3 pixmap and would avoid a couple of QPixmap<->QImage conversions.

> That reminds me: Someone asked me if and how KGameRenderer can
> make use of style-aware colors. (I think Amarok uses that for their
> interface, to match the system color scheme.) The concrete usecase is a
> sprite of a player avatar in which the player's color can be inserted.
>
> Do you know how to do that, which code to read, or whom to talk to?

One potential way would be to edit the SVG as a XML file before
loading. I think SVG allows one to define named colours and use them
elsewhere. So if those definitions where altered just prior to loading
the SVG, you could swap out various colours "as the artist intended".
Of course, then that QSvgRenderer would only be good for a certain
colour combination and you would have to reedit and load the SVG every
time you wanted to make a change. Actually the more I describe this,
the more I think this might not be the best way, as it would probably
require hand editing the SVG.

Parker