[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-20 21:41:45
[Download RAW message or body]

Hi again!

> How about this:
> 
> create a base class for timed objects:
> class TimedObject
> {
> public:
>     virtual void tick() = 0;
> };
> 
> Every sprite inherits from this.

So far, that would indeed be the approach, only that I would add an int 
parameter as an identifier in case one sprite needs several timers (very much 
like with the QObject-timers).

> For every different timing interval you create an instance of the following
> class:
> 
> class TimeManager : public QObject
> {
> Q_OBJECT


I'm not sure, whether this is smart, though. The original question was, 
whether I should try getting rid of some QObjects (in case I got this wrong: is 
there a particular (black magic) problem about classes that inherit from both 
QCanvasSprite and QObject, or is it simply that of QObjects being large and 
slow?), while this approach would (at least for my particular game) result in 
roughly the same amount of QObjects or even more (unless of course, those 
TimeManagers that are currently unneeded (no TimedObject with that timer-
period) get deleted and created again when needed - but my (naive) estimate 
would be that this would cause too much overhead to be of much use.
Rather, the approach that I would favor would be to have only one instance of 
a TimeManager-class connected to a real timer at a reasonably high 
resolution (say at 10 ms, might however be run-time-configurable without too 
much trouble). Using your code, this object would then have the functions
 
public:
     int addTimedObject(TimedObject* to, int period)
     {
         if (to != 0)
         {
              // add to internal list containing id-code, TimedObject*, a 	
	  // score var and an increment (large for short periods, small
	  // for longer periods):
	  int increment = (100 * basePeriod) / period;
	  // (if period > 0, of course). * 100 is to ensure good
	  // accuracy without the need for double vars
         }
         return id;
     }
 
     void removeTimedObject(int id)
     {
         if (to != 0)
         {
             // remove from internal list
         }
     }
 
protected slots:
     // connect this to timeout() of a QTimer
     void slotTimeOut()
     {
          // iterate through list
          // increase score on all objects,
          // call tick() (possibly several times) on each element
          // where score >= 100 .
          // possibly even call canvas->advance () in here, instead of
          // using setAdvancePeriod?
     }
};
 
This way, you would only have a single QObject for the timing, the syntax 
would remain pretty similar to timer / timerEvent. I still don't know, whether 
and by how much this would reduce resource-consumption - but by now I'm 
curious enough so that probably I'll give it a try. Not sure, how soon I'll get 
around to do this + I will also have to remove some signals and slots to truly 
get rid of those QObjects, but I'll report on it when done.

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]