[Kde-games-devel] KGameRenderer v. KGoldrunner: some problems

Mathias Kraus k.hias at gmx.de
Sun May 20 06:33:43 UTC 2012



Am Sonntag, 20. Mai 2012, 15:25:35 schrieb Ian Wadham:
> Hi guys, especially Stefan,
> 
> It looks as though KGoldrunner has some problems regarding the
> use of KgView, KgViewProvider and KGameRenderer.
> 
> 1. Every theme has *two* SVG files: one for "set" (the tiles, gold,
>     ladders, etc.) and one for "actors" (the hero and enemies).
>     Also the .desktop files have Set and Actors attributes, rather
>     FileName.
> 
> 2. The themes contain elements with a variety of suffix formats:
>     -%1, _%1 or even %1.
> 
> 3. Some suffixes start at 0 and some start at 1.
> 
> 4. Some suffixes are optional, depending on whether the artist
>     has drawn more than one version of an element, e.g. you can
>     have "background0", "background1", etc. or just "background".
> 
> I think point 4 is already handled by KGameRenderer::frameCount().
> 
> On points 2 and 3, I am not clear on whether setFrameSuffix() and
> setFrameBaseIndex() can be used repeatedly with different parameters
> or whether they are for use once-only per KGameRenderer.  If
> once-only, we have a problem.
> 
> Re point 1, would it work to change "Set" to "FileName" in the .desktop
> files and have Actors as a custom attribute, then have a *second*
> (artificially constructed) KgTheme and a *second* KGameRenderer to
> provide the pixmaps for hero and enemies?  Or would that mess up the
> cacheing?
> 
> At present, KGoldrunner has two QSvgRenderer's but puts all pixmaps
> in the same cache.  Having two caches, one per KGameRenderer,
> should not be a problem.
> 
> Would the above ideas work?  Any other ideas?

It should work. In Granatier I use several KGameRenderer (and KgTheme) 
intances, up to two for the theme and one for each player, with no problems.

> Thanks in advance, Ian W.
> 
> P.S. I do not like the idea of manually merging and committing the pairs
> of huge binary files KGoldrunner has for its themes, but that might be
> a brute-force way to solve problem 1, if it can be done reliably and
> without large overheads on the repository.
> 
> 
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel


More information about the kde-games-devel mailing list