Qt : Efficiently handle QGraphicsItems that have "lots of pixmaps"? (RTS)

Question

I'm currently building up a small Real Time Strategy 2D engine. And I wonder how to handle the many everchanging sprites that will eventually cluter my screen.

FYI, I am not aiming at anything AAA level, I'm just trying to implement some machine learning methods. Thus, I've picked Warcraft II abandonware ISOs, took shamelessly some graphics, and I've tumbled on the first issues.

http://img263.imageshack.us/img263/1480/footman.png

As you can see above, even the simple footman of Warcraft II has got around 50 sprites for its animation. Which is a lot. And it will change sprites very often. (The black line was just checking if my alpha channel was right)

Thus, the final question : How do I implement efficiently a QGraphicsObject that keeps on changing? How do I efficiently implement a QGraphicsItem that repeatedly changes its appearance?

Do I simply overload the paint() method of QGraphicsPixmapItem and keep on changing the Pixmap used on screen? Will it cause some "stuttering"? I've heard that sometimes, it is wise/possible to create one all the pixmaps, hide them all, and duplicate them when needed. (Copy is less expensive than other operations) Is there any other intelligent idea?

Thanks for any input! (tutorial for RTS engines, complexity stuff, etc...)

Answer 1

(I'll start with the general idea first, a possible Qt implementation will follow)

I don't know how are WCII sprites stored, but you should use a sprite sheet (building it yourself if needed). Associated to this sheet, you'll have some description of the sprite containing at the very least the list of animations, and for each animation, it's identifier/name, as well as a list of frames.

The level of detail you put in describing those animation's frames is up to you, but must contain at the very least the rectangle of the sprite sheet to display.

As an example, take a look at this sprite sheet (clearly not optimized, but for an example, it's okay :)). Here's the associated animations descriptions (line 12 to 39). All animations aren't included, but you'll get the idea.

You can see that the "idle" animation is made from 3 frames, which sub-rects match to the first 3 frames in the sprite sheet. Associated to the sub-rect, there are 2 more information in this sample:

• duration: how long should the frame be displayed before moving on to the next?
• origin: what's the anchor point of the frame?

Now, how would you go over implementing that in Qt?

The animations' description file format is entirely up to you, but I recommend some hierarchy file format. Since Qt provides XML parser, it can be perfect. If you're used to boost and prefer a lightweight format like JSon, you can use boost.ptree to parse indifferently XML/JSon files and have a common interface to extract data from them.

For the graphics representation, you'll have to use some classes:

• QPixmap: from which we'll draw sub-rectangles matching animations' frames,
• a QTimer to update your sprites,
• your very own display class, say AnimatedSprite (derived from a QGraphicsObject, you'll need the signal/slots support),
• and a support class, say TimerProxy (derived from a QObject).

I'll start by describing the TimerProxy role. It's role is to send time update messages. It's here because Qt Graphics objects don't provide any kind of "timed" update (ie, update(float dt) where dt is given is your favorite unit of time). You may wonder why we're using a proxy class to handle time. This is to limit the quantity of active QTimer; if you have one of these per AnimatedSprite, you might end up having tons of timers active which clearly is a big no-no.

So it fulfills 2 roles:

• at scene's construction time: all AnimatedSprite will register themselves to a signal it provides, let's name it updateTime(int msecs),
• at scene runtime, it'll start a QTimer which timeout is set to the granularity you need (you can go on with 16ms for an approximated 60 fps). QTimer's signal timeout() will be associated to a private slots which will fire the updateTime(int msecs) where msecs is set to the timer's granularity you set before.

Now, for the core of the solution: AnimatedSprite. This class has the following roles:

• reading & storing the animations' description it'll need,
• starting, updating & stopping animations
• drawing the active sprite's frame on the QGraphicScene

At initialization, you should give it the following info:

• an instance of TimerProxy (owned by your scene, or the class owning the scene). When provided this instance, you just connect the TimerProxy::updateTime(int) signal to a private slots which will update the current animation,
• the QPixmap holding the spritesheet,
• and the animations descriptions

During runtime, the update methods will look like:

• a private timeUpdated(int) slot which will check if the current animation's frame should be updated, and update it accordingly,
• public animations method, like startAnim(const QString &animName), which will change the current animation, reset the elapsed time counter, and update the current sub-rect to draw to match the first frame of the new animation.

In the timeUpdated(int) slot, you want to update your elapsed time, and check if it should make the animation proceed to next frame. If so, just update the current frame pointer to the new frame.

Lastly, to render, you just reimplement QGraphicsItem::paint(...) method to draw the current subrect, which might look like:

void AnimatedSprite::paint(QPainter *painter,
                           const QStyleOptionGraphicsItem * /*option*/,
                           QWidget * /*widget*/)
{
    painter->drawImage(mCurrentAnim.mCurrentFrame->mOrigin,
                       mSpriteSheet,
                       mCurrentAnim.mCurrentFrame->mSubRect);
}

Hope that helps (and isn't too big, wow :s)