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

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] QCanvasSprite + QObject
From:       thomas.friedrichsmeier () ruhr-uni-bochum ! de
Date:       2001-12-18 22:51:22
[Download RAW message or body]

Hi!

> There is a reason why Warwick has choosen not to have CanvasSprites 
> inherting from QObject. QOjbects are big and might slow down the canvas 
> processing if you have many of them (which is usually the case with a 
> Canvas).
> 
> If you ever experience very slow games, you could move from a signal/slot 
> communication to an event driven communcation : define a new 
> QCanvasSpriteEvent with the info you would put inside the signal, put this event
> on the Qt event list and get the event elsewhere in your canvas. It should be
> quicker than signal/slot although slightly more complicated.

This got me interested. In a previous mail I complained about some sudden 
slowdowns, but whether or not this particular problem is related to QObjects 
(or rather to some nifty stupidity of mine), performance could be better in my 
game.
I wonder however, just how big and slow QObjects are - can anybody supply 
details? I typically have between four and ten QCanvasSprite/QObject-things 
on my canvas which don't exchange too many signals (I'd think something 
like one per second on average), but use the timers / TimerEvent of QObject 
for doing their animations. So is it worth the (substantial) hassle of rewriting 
the respective classes to get rid of QObject? Anybody have experience with 
this?

In case anybody wants to have a look at it: 
http://taxipilot.sourceforge.net

Thomas
_______________________________________________
kde-games-devel mailing list
kde-games-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-games-devel
[prev in list] [next in list] [prev in thread] [next in thread]