[Kde-games-devel] Helping with KGameRenderer porting

[Brian Croom]

2010/8/9 Stefan Majewsky <kdemailinglists at bethselamin.de>

> On Monday 09 August 2010 10:03:32 Brian Croom wrote:
> > Anyway, after a couple
> false starts on games that turned out to be a bit
> > more complicated than I
> anticipated, I managed to get some work done,
> > porting KReversi[1],
> Kapman[2], and KAtomic[3] this weekend.
>
> Terrific! I didn't imagine you
> would come up to speed so fast.
>
> > I'm not so
> > sure what the proper
> procedure for patch submission and such is, so I've
> > uploaded them to a
> server (does the mailing list accept attachments?) for
> > now.
>
> The
> mailinglist accepts attachments, though the recommended method is
> http://reviewboard.kde.org. Create an account and upload your diffs (the
> base directory is most probably "trunk/KDE/kdegames" or the subdirectory of
> it where you created the patch). Unfortunately, Reviewboard has problems
> sometimes when your patch does not come straight from "svn diff". If such
> problems arise, just post the patches to the mailing list.
>
> > --
> QGraphicsItem and related classes accept a QGraphicsScene* in their
> >
> constructors, although this is marked as obsolete in their header files
> and
> > this parameter is not mentioned at all in the docs.
> KGameRenderedItem
> > (sensibly) doesn't have this parameter, however many of
> the games
> > instantiate QGraphicsItem derivatives passing in a scene. As
> best as I can
> > tell, the equivalent is to call the scene's addItem method
> instead of
> > passing in the scene. Is that the correct equivalent?
>
> Short
> answer: Yes.
> Long answer: Be cautious to call scene->addItem() _immediately_
> after creating the item, before setting any other properties. I know that
> addItem() resets at least QGraphicsItem::pos. When I port items with such
> constructors, I usually leave the constructor signature as-is and insert
> "if
> (scene) scene->addItem(this)" as the first statement in the constructor.
>
Gotcha. I'll keep that in mind.

>
> >
> -- I had experienced segmentation faults when calling KGameRenderer's
> >
> boundsOnSprite and frameCount methods immediately after instantiating the
> >
> renderer. Apparently the renderer doesn't load the images from the SVG
> >
> until a pixmap is requested?
>
> I think that I fixed this problem on Saturday.
> Please update to a revision >=1160372 and check whether the problem is
> still
> there.
>
Lovely! That seems to have fixed it.

>
> > -- Some games (e.g. KBattleship) use KGameCanvas and related
> classes which
> > seem to offer functionality similar to QGraphicsView and
> friends. I'm
> > guessing these classes were written before the introduction
> of
> > QGraphicsView? Should games using these be ported to use QGraphicsView?
> Or
> > is there another strategy for handling them?
>
> Yes, KGameCanvas was
> created way before QGraphicsView. That was even before my time, so I do not
> know KGameCanvas. I would say, just leave the applications. When I have
> some
> time, I'll read into KGameCanvas and create a KGameRendererClient subclass
> to enable porting.
>
> > -- It seems common for classes derived from
> QGraphicsPixmapItem to get a
> > pixmap from an SVG renderer and then modify
> it in some way with a QPainter,
> > either by overlaying/underlaying another
> Pixmap or by using the basic
> > drawing tools. KReversi marks the last-played
> chip in this way. I worked
> > around it by using opacity for doing the
> marking instead. KAtomic creates
> > pixmaps which are a composite of the atom
> element and the bond elements
> > from the SVG. In this case I made the atom
> class have children items with
> > the SVG elements for the atomic bonds. What
> other strategies are there for
> > handling cases where using the basic SVG
> pixmap (as received from the
> > KGameRenderer) isn't sufficient?
>
> When the
> item composes several pixmaps, the right strategy IMO is to compose
> multiple
> KGameRenderedItems, as you did with KAtomic.
>
> If the transformation is
> applied to the pixmap directly, and cannot be modeled with QGraphicsItem
> parameters, you could try to subclass KGameRenderedItem, and reimplement
> the
> receivePixmap() method to modify the received pixmap before passing it to
> the base class implementation.
>
> > -- I found what I am taking to be a bug in
> KGameRenderer regarding the
> > deletion of its KGameRendererClient classes.
> The KGameRenderer destructor
> > currently takes a copy of the list of clients
> and uses qDeleteAll to free
> > the objects. However, if one of the clients
> has child objects which are
> > also clients and come later in the renderer's
> client list, then the
> > renderer will attempt to delete them again (when it
> comes across them in
> > the list) even though they were already deleted when
> their parent was
> > deleted. I ran into this while working on KAtomic. The
> simplest workaround
> > was to explicitly delete any objects that had
> KGameRendererClients as
> > children in the scene destructor instead of
> waiting for them to be deleted
> > as members of the scene, however this still
> seems to be a KGameRenderer
> > bug. The fix is to check before deleting each
> client if it still is
> > present in the "canonical" clients list. Here is a
> patch implementing that
> > [4]. What do you think?
>
> I'm about to leave now,
> and will have a look at this tonight.
>
I also just found a documentation issue. The docs for
KGameRendererClient::frameCount claims that it returns "the frame count, or
-1 for non-animated frames", however this is incorrect. It actually returns
the value from KGameRenderer::frameCount, whose return value is "the count
of frames available for the sprite with this *key* If this sprite is not
animated (i.e. there are no SVG elements for any frames), this method
returns 0. If the sprite does not exist at all, -1 is returned."

>
> Greetings
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20100809/27f13669/attachment-0001.htm