[Kde-games-devel] Moving the KGameRenderer framework to pseudo-kdereview
Stefan Majewsky
kdemailinglists at bethselamin.de
Sun Jul 4 17:37:48 CEST 2010
On Sunday 04 July 2010 00:01:46 Parker Coates wrote:
> Does that mean that KGameRenderedItem no longer has a setOffset()
> method? I use that in Killbots.
I'll add one.
> I'm also concerned with the potential runtime cost of doubling the
> number of items in the scene. Would you mind elaborating on why you
> felt the need to switch to QGraphicsObject? My understanding was that
> it was only a convenience class for handling the QObject::parent()
> QGraphicsItem::parent() conflict and the Q_INTERFACE.
There is no conflict between the parent() methods because it's
QGraphicsItem::parentItem() for exactly this reason. (Also, the APIDOX
suggests to use QGraphicsItem::setParentItem and NOT QObject::setParent to
model QGraphicsObject hierarchies.)
Then QGraphicsObject provides the properties, change signals, quick casting. I
could copy all of this into KGRI, but sharing the implementation is especially
good for future-proofness. If, say, Qt 4.8 brings a new feature in
QGraphicsObject which is desperately needed by us, then I have no chance to
use it if KGRI is QObject/QGraphicsPixmapItem-derived. With the
QGraphicsObject superclass, I can stuff anything I like into KGRI internally.
On the runtime cost: It should not be much. Graphics View is designed to
handle thousands of items (see the "chip" demo which comes with Qt) without
producing much overhead. Perhaps someone of the Qt devs reading k-d@ could
coment on that?
Apart from all that, moving the QGraphicsPixmapItem into the KGameRenderedItem
internals allows me to play with its coordinate system in interesting ways.
The addition of the primaryView property and the associated fixation of the
coordinate system actually were totally necessary to enable porting of Kolf
(which I'm working on currently).
Greetings
Stefan
More information about the kde-games-devel
mailing list