<br><br><div class="gmail_quote">2010/8/9 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 Monday 09 August 2010 10:03:32 Brian Croom wrote:<br>
> Anyway, after a couple<br>
false starts on games that turned out to be a bit<br>
> more complicated than I<br>
anticipated, I managed to get some work done,<br>
> porting KReversi[1],<br>
Kapman[2], and KAtomic[3] this weekend.<br>
<br>
</div>Terrific! I didn't imagine you<br>
would come up to speed so fast.<br>
<div class="im"><br>
> I'm not so<br>
> sure what the proper<br>
procedure for patch submission and such is, so I've<br>
> uploaded them to a<br>
server (does the mailing list accept attachments?) for<br>
> now.<br>
<br>
</div>The<br>
mailinglist accepts attachments, though the recommended method is<br>
<a href="http://reviewboard.kde.org" target="_blank">http://reviewboard.kde.org</a>. Create an account and upload your diffs (the<br>
base directory is most probably "trunk/KDE/kdegames" or the subdirectory of<br>
it where you created the patch). Unfortunately, Reviewboard has problems<br>
sometimes when your patch does not come straight from "svn diff". If such<br>
problems arise, just post the patches to the mailing list.<br>
<br>
> --<br>
<div class="im">QGraphicsItem and related classes accept a QGraphicsScene* in their<br>
><br>
constructors, although this is marked as obsolete in their header files<br>
and<br>
> this parameter is not mentioned at all in the docs.<br>
KGameRenderedItem<br>
> (sensibly) doesn't have this parameter, however many of<br>
the games<br>
> instantiate QGraphicsItem derivatives passing in a scene. As<br>
best as I can<br>
> tell, the equivalent is to call the scene's addItem method<br>
instead of<br>
> passing in the scene. Is that the correct equivalent?<br>
<br>
</div>Short<br>
answer: Yes.<br>
Long answer: Be cautious to call scene->addItem() _immediately_<br>
after creating the item, before setting any other properties. I know that<br>
addItem() resets at least QGraphicsItem::pos. When I port items with such<br>
constructors, I usually leave the constructor signature as-is and insert "if<br>
(scene) scene->addItem(this)" as the first statement in the constructor.<br></blockquote><div>Gotcha. I'll keep that in mind. <br></div><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"><br>
><br>
-- I had experienced segmentation faults when calling KGameRenderer's<br>
><br>
boundsOnSprite and frameCount methods immediately after instantiating the<br>
><br>
renderer. Apparently the renderer doesn't load the images from the SVG<br>
><br>
until a pixmap is requested?<br>
<br>
</div>I think that I fixed this problem on Saturday.<br>
Please update to a revision >=1160372 and check whether the problem is still<br>
there.<br></blockquote><div>Lovely! That seems to have fixed it. <br></div><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"><br>
> -- Some games (e.g. KBattleship) use KGameCanvas and related<br>
classes which<br>
> seem to offer functionality similar to QGraphicsView and<br>
friends. I'm<br>
> guessing these classes were written before the introduction<br>
of<br>
> QGraphicsView? Should games using these be ported to use QGraphicsView?<br>
Or<br>
> is there another strategy for handling them?<br>
<br>
</div>Yes, KGameCanvas was<br>
created way before QGraphicsView. That was even before my time, so I do not<br>
know KGameCanvas. I would say, just leave the applications. When I have some<br>
time, I'll read into KGameCanvas and create a KGameRendererClient subclass<br>
to enable porting.<br>
<div class="im"><br>
> -- It seems common for classes derived from<br>
QGraphicsPixmapItem to get a<br>
> pixmap from an SVG renderer and then modify<br>
it in some way with a QPainter,<br>
> either by overlaying/underlaying another<br>
Pixmap or by using the basic<br>
> drawing tools. KReversi marks the last-played<br>
chip in this way. I worked<br>
> around it by using opacity for doing the<br>
marking instead. KAtomic creates<br>
> pixmaps which are a composite of the atom<br>
element and the bond elements<br>
> from the SVG. In this case I made the atom<br>
class have children items with<br>
> the SVG elements for the atomic bonds. What<br>
other strategies are there for<br>
> handling cases where using the basic SVG<br>
pixmap (as received from the<br>
> KGameRenderer) isn't sufficient?<br>
<br>
</div>When the<br>
item composes several pixmaps, the right strategy IMO is to compose multiple<br>
KGameRenderedItems, as you did with KAtomic.<br>
<br>
If the transformation is<br>
applied to the pixmap directly, and cannot be modeled with QGraphicsItem<br>
parameters, you could try to subclass KGameRenderedItem, and reimplement the<br>
receivePixmap() method to modify the received pixmap before passing it to<br>
the base class implementation.<br>
<div><div></div><div class="h5"><br>
> -- I found what I am taking to be a bug in<br>
KGameRenderer regarding the<br>
> deletion of its KGameRendererClient classes.<br>
The KGameRenderer destructor<br>
> currently takes a copy of the list of clients<br>
and uses qDeleteAll to free<br>
> the objects. However, if one of the clients<br>
has child objects which are<br>
> also clients and come later in the renderer's<br>
client list, then the<br>
> renderer will attempt to delete them again (when it<br>
comes across them in<br>
> the list) even though they were already deleted when<br>
their parent was<br>
> deleted. I ran into this while working on KAtomic. The<br>
simplest workaround<br>
> was to explicitly delete any objects that had<br>
KGameRendererClients as<br>
> children in the scene destructor instead of<br>
waiting for them to be deleted<br>
> as members of the scene, however this still<br>
seems to be a KGameRenderer<br>
> bug. The fix is to check before deleting each<br>
client if it still is<br>
> present in the "canonical" clients list. Here is a<br>
patch implementing that<br>
> [4]. What do you think?<br>
<br>
</div></div>I'm about to leave now,<br>
and will have a look at this tonight.<br></blockquote><div>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 <em>key</em>
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."</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Greetings<br>
<font color="#888888">Stefan<br>
</font></blockquote></div><br>