[Kde-games-devel] QCanvas replacement?

[Mathieu Jobin]

personnaly i would love to use a QWidjet as a QCanvasItem


On Friday 04 October 2002 05:47 am, by way of Ralf Schmelter 
ralf.schmelter@t-online.de wrote:
> 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
> from 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
> pixmap (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 like
> kyra (http://www.grinninglizard.com/kyra/) or evas from the enlighment
> project (http://enlightenment.org/pages/evas.html). These engines
> concentrate on using sprites (and not text or other geometrical primiteves)
> and use different backends for displaying them (OpenGL if available and
> framebuffer 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 also supported and when using a z-buffer you don't even have to
> sort the sprites 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). So 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 features
> this should not be too hard, but e.g. scaling, rotating and alpha blending
> can be a problem. If a game relies on these features, it might happen, that
> the game speed is unbearable without using OpenGL. While you can use
> prescale 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 which
> uses the techniques described above to deliver the performance and
> graphical 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 and
> 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 uses
> some feature, so that it can decide not to use it, if it is not absolutely
> nescessary (e.g. to use a simple alpha mask instead of full alpha
> blending)?
>
> Ralf
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-games-devel