[Kde-games-devel] QCanvas replacement?

[by way of Ralf Schmelter ralf.schmelter@t-online.de]

Hiho!

After working some time with QCanvas, I began to wonder, if it is really =
the
right tool when creating games. The advantages of QCanvas, as I seem them
are:
- Delivered with Qt, so no work is needed to update QCanvas to the newest
technology (for example to make use of new XRender functions).
- Supports sprites (pixmaps), text and other graphical primitives knwon f=
rom
Qt itself.
- It's stable.
- You can have multiple views of the canvas.
- You have collision detection.
But there are of course some drawbacks:
- QCanvas is not very fast. If you have lots of action and lot of
 QCanvasItems displaying is mostly to sloppy.
- Alpha channel handling is only rudimentary implemented.
- The programming interface is sometimes awkward. For example to create a
sprite, you have to create a QPixmapArray, which in turn wants a QPtrList=
 of
QPixmaps. Thats quite a lot of work, if you only want a sprite with on pi=
xmap
(the common case I think).
- Scaling (and worse rotation) the view is usabe only in theory (see for
example the effect it has, when you scale the map in Boson).

After searching for alternatives, I've stunbled across sprite engines lik=
e
kyra (http://www.grinninglizard.com/kyra/) or evas from the enlighment
project (http://enlightenment.org/pages/evas.html). These engines concent=
rate
on using sprites (and not text or other geometrical primiteves) and use
different backends for displaying them (OpenGL if available and framebuff=
er
or XRender if not). And if you think about it, OpenGL is clearly the
preferred choice. It's extremely fast, supports scaling and rotating out =
of
the box with only a small (if any) overhead, alpha channel handling is al=
so
supported and when using a z-buffer you don't even have to sort the sprit=
es
with regard to their z-coordinate. The only problem I see is the state of=
 the
OpenGL drivers for Linux. While nVidia's drivers are excellent from a
performance point of view, others are not, so one has to have at leat one
other engine to rely on if OpenGL is not available or too instable. This =
of
course can be a serious problem (especially of OpenGL is too unstable). S=
o
one has to develop a fallback backend, which should have the same
capabilities as OpenGL, only that it is not as fast. For the basic featur=
es
this should not be too hard, but e.g. scaling, rotating and alpha blendin=
g
can be a problem. If a game relies on these features, it might happen, th=
at
the game speed is unbearable without using OpenGL. While you can use pres=
cale
pixmaps for the scaling problem (at the expense of using more memory),
rotating and alpha blending are a much tougher problem (although the last
seems to be adressed in the new XRender architecture).

So, the question arises, if it would make sense to develop a KCanvas whic=
h
uses the techniques described above to deliver the performance and graphi=
cal
features needed to program games which need them? If the answer is yes, I
think we should first define the operations needed by the games.
For example:
- do we need to have multiple views of the canvas?
- do we have to support scaling and/or rotating for every sprite?
- do we have to include text (probably) and other graphical primitives an=
d if
yes, to we convert them just into sprites?
- what kind of backends to we want (OpenGL, XRender, QCanvas, SDL)?
- should we give the game some hints about expected performance if it use=
s
some feature, so that it can decide not to use it, if it is not absolutel=
y
nescessary (e.g. to use a simple alpha mask instead of full alpha blendin=
g)?

Ralf