[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [Kde-games-devel] Moving the KGameRenderer framework to
From:       Stefan Majewsky <kdemailinglists () bethselamin ! de>
Date:       2010-07-05 20:08:01
Message-ID: 201007052308.03365.kdemailinglists () bethselamin ! de
[Download RAW message or body]

On Monday 05 July 2010 16:50:13 Parker Coates wrote:
> Sorry, I realise that it's not an API conflict, I should have been
> clearer. I just meant that if you manually derive from QObject and
> QGraphicsItem, you're dealing with two parental hierarchy that can
> sometime conflict if your not careful.

Agreed, though I do not see how this is relevant to the discussion. Both the 
QObject and QGraphicsItem subclasses are needed, so this problem is actually a 
Qt problem (though "problem" is the wrong word, they did not derive 
QGraphicsItem from QObject for good reasons).

> It's not actually the runtime performance that concerns me so much as
> the clunkiness the nested items adds from the library user's
> perspective. Iterating through QGraphicsScene::items() or
> collidingItems() or itemsAt() now takes twice as long, and the user is
> expected to know which items he is allowed to touch and which ones he
> isn't. Calling itemAt() will likely return the "wrong" item and one
> will have to check that and get the parent item. And so on.

Agreed again. I did not look from this perspective even though I suffered from 
these problems in the port of Kolf which I'm doing in my Git repo besides 
other things.

I have solved this problem now with a fancy trick: I call the 
QGraphicsPixmapItem implementations of the subitem from the corresponding 
functions of the KGameRenderedItem, and reimplement empty the functions for 
the subitem. This way, I can reuse the QGraphicsPixmapItem reimplementation, 
but itemsAt() and friends will only see one item.

> Having thought about this, QGraphicsPixmapItem doesn't really do
> anything that fancy (ignoring the masking shape stuff, but I'm not
> sure anybody in KDEGames is using that as it's quite expensive and
> only needed for very fine collision detection of irregular shapes).

The fine collision detection is an important detail which I do not want to 
miss in KDiamond, esp. for irregularly shaped diamonds. It was therefore out 
of question for me from the beginning to scrap the QGraphicsPixmapItem 
implementation completely.

Greetings
Stefan
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]