[Kde-games-devel] Helping with KGameRenderer porting

[Stefan Majewsky]

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.

>
-- 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.

> -- 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.

Greetings
Stefan