[Kde-games-devel] Helping with KGameRenderer porting

Mon Aug 9 10:03:32 CEST 2010

Hi,

I succeeded in getting the development environment set up and working. After
surfing the docs for a while, I was pleasantly surprised at how straight
forward it was to just get kdegames working, and it's a small enough module
that compiling everything wasn't too painful despite the Atom processor in
this machine :)

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. 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. I'm
sure there is plenty of room for improvement, but they seem to work just
fine in my testing so far, and I've learned a lot already. I do have a few
specific questions/issues about things that came up:

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

-- 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 worked around this by calling
KGameRenderer::spritePixmap on an arbitrary sprite and throwing away the
return value. Is there a cleaner way to do this? Should KGameRenderer be
modified to load the data when these methods (as well as spriteExists) are
called?

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

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

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

--Brian

[1] http://cs.wheaton.edu/~bcroom/patches/kreversi.diff<http://cs.wheaton.edu/%7Ebcroom/patches/kreversi.diff>
[2] http://cs.wheaton.edu/~bcroom/patches/kapman.diff<http://cs.wheaton.edu/%7Ebcroom/patches/kapman.diff>
[3] http://cs.wheaton.edu/~bcroom/patches/katomic.diff<http://cs.wheaton.edu/%7Ebcroom/patches/katomic.diff>
[4] http://cs.wheaton.edu/~bcroom/patches/kgamerenderer.diff<http://cs.wheaton.edu/%7Ebcroom/patches/kgamerenderer.diff>

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

> On Saturday 07 August 2010 04:09:39 Brian Croom wrote:
> > I've just joined
> this list and am responding to Stefan Majewsky's blog
> >
> posting<
> http://majewsky.wordpress.com/2010/08/06/junior-job-kgamerenderer-p
>
> > orting/>(seen on Planet KDE) about a "junior job" involving porting games
> >
> to use KGameRenderer etc.
>
> Woohoo, my plan worked! Welcome to kdegames!
>
> >
> I have been coding with C++ for a long time and consider myself proficient
> >
> with the language, but have no experience to speak of with Qt. I'd like to
> >
> learn!
>
> Some experience with Qt would be good. The documentation [1]
> includes excellent tutorials.
>
> > I would appreciate pointers about getting a
> development environment
> > set up. How much of the KDE source tree will I
> need to check out in order
> > to build the KDE games?
> >
> > My development
> system is currently running Ubuntu
> > 10.04; can I use the Qt development
> packages from the repos (4.6.2) or do
> > I need something more recent? I
> don't have any KDE packages installed on
> > here currently but I would still
> like to keep development stuff
> > self-contained, i.e. not installed into
> /usr and such. How difficult is
> > that going to be?
>
> Qt 4.6 is the current
> requirement for KDE trunk. (We won't rely on Qt 4.7 before it's released.)
> You basically need two KDE modules: kdelibs (of course) and kdegames. For
> kdelibs, it will suffice to use the version from KDE SC 4.5, which should
> be
> available for Kubuntu (at least the current RC2, the final version is due
> Wednesday).
>
> So if you have kdelibs 4.5 installed already, you will only
> need to checkout the kdegames source tree [2][3], which contains the games
> themselves and the libkdegames in which you find the KGameRenderer classes.
> General information about setting up a self-contained KDE development
> environment is in our techbase wiki at [4]. If you have trouble following
> these descriptions, you can also find help on kde-devel at kde.org or on
> Freenode IRC (#kdegames).
>
> > If someone could provide a synopsis of what the
> new KGameRenderer
> > class(es?) is/are for and the reasons for the porting,
> that would be
> > helpful as well.
>
> A basic explanation is in a previous
> blogpost of mine. [5] The basic reason is that we have about 30 games in
> the
> module which all implement their own SVG rendering and caching classes.
> This
> brings all the usual problems of bloat: fixing a bug or implementing a
> clever caching strategy in one app won't benefit the others, 30
> implementations means a 30-fold higher chance of bugs, etc. Add to that
> that
> we are currently quite low on manpower, and you'll understand why I try to
> reduce the codesize by sharing code via libraries.
>
> For more reference on
> KGameRenderer is and how to use it, have a look at the API documentation
> [6]
> or at the code of KDiamond, Killbots and KSame, which have already been
> ported.
>
> > I'm looking forward to working with you!
>
> So do I! Please let me
> know if you have any further questions.
>
> Greetings
> Stefan
>
> [1]
> http://qt.nokia.com/doc/4.6/
> [2]
> svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames/
> [3]
> http://websvn.kde.org/trunk/KDE/kdegames/
> [4]
> http://techbase.kde.org/Getting_Started/Build/KDE4
> [5]
>
> http://majewsky.wordpress.com/2010/06/13/kgamerenderer-caching-on-multiple-l
> evels/<http://majewsky.wordpress.com/2010/06/13/kgamerenderer-caching-on-multiple-l%0Aevels/>
> [6]
>
> http://api.kde.org/4.x-api/kdegames-apidocs/libkdegames/html/classKGameRende
> rer.html<http://api.kde.org/4.x-api/kdegames-apidocs/libkdegames/html/classKGameRende%0Arer.html>
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20100809/6283edad/attachment-0001.htm 