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