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

[Ian Wadham]

Thanks very much for your reply and advice, Stefan.

On 24/05/2012, at 4:51 AM, Stefan Majewsky wrote:
> On Sun, May 20, 2012 at 7:25 AM, Ian Wadham <iandw.au at gmail.com> wrote:
>> 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?
> 
> I'd say, create two KgThemeProviders and map the theme selection of
> the one provider to the other one by a signal-slot connection.
> 
> The theme files you can leave like they are now. Instead create two
> KgTheme subclasses, with a reimplementation of readFromDesktopFile,
> e.g.
> 
> bool KgrActorTheme::readFromDesktopFile(const QString& path) {
>    //base class call
>    if (!KgTheme::readFromDesktopFile(path))
>        return false;
>    //custom behavior: interpret "Actor" key as "FileName"
>    setGraphicsPath(customData("Actor"));
>    return true;
> }
> 
> Remember to include Q_OBJECT in the definition of the KgTheme
> subclasses, then give the optional QMetaObject parameter to
> KgThemeProvider::discoverThemes to make sure that it picks up your
> KgTheme subclasses (see documentation):
> 
>    actorProvider->discoverThemes(..., ..., ...,
> KgrActorTheme::staticMetaObject());
> 
> All this from the top of my head, but it should work. That's one of
> the various customization hooks that KgTheme provides.

Yes, good idea.  I'll give it some further thought and some prototyping.

> Re frameSuffix() and friends, they're indeed designed as unique per
> KGameRenderer instance. If adjusting the theme is not an option for
> you, you'll have to roll your own frame management. Frame management
> in KGameRenderer is mostly syntactic sugar, because
> 
>    setFrame(frame);
> 
> looks nicer than
> 
>    setSpriteKey(QString("foobar-%1").arg(frame));
> 
> You can do the frame management on your own without problems. For
> example, have a look at how frameCount() is implemented with
> QSvgRenderer::elementExists()., Now QSvgRenderer::elementExists() is
> equivalent to KGameRenderer::spriteExists() if you set the
> frameBaseSuffix to a string that is never a valid suffix, e.g.
> QString("FOOBARQUX").

frameBaseSuffix ??? :-)   Actually I think frameSuffix defaults to "_%1" if you
hand it an invalid suffix.  Never mind.  All my animation pixmaps (runners
and dug bricks) use suffix "_%1" and base 1, with fixed frame counts, so no
problem with those.

The other suffixed SVG elements are for optional extra backgrounds and
tile variants.  KGoldrunner already does existence tests and frame counts
for them.  If we use KGameRenderer::spriteExists() with "brick-0" or
"background0", I am sure there will be no "brick-0_1" or "background0_1"
to be found.  False will mean that there is just "brick" or "background", with
no variants.

Thanks again, Stefan.

Cheers, Ian W.