KGameCanvas

Hi, guys. I commited the small changes needed to solve the
group update
issue I reported before. It turns out that they were already
fixed in the
latest SVN as part of an unrelated change made by Maurizio,
two days ago.

The light canvas class is now available in libkdegames as
KGameCanvas.
KGoldRunner is using the library version already, and
KMahjongg drawing
code is implementing it right now, as I want to have very
fine control of
SVG->Pixmap cacheing behavior.

Regards,
Mauricio Piacentini


_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Saturday 30 September 2006 16:11, mauriciotabuleiro.com wrote:
> Hi, guys. I commited the small changes needed to solve
the group update
> issue I reported before. It turns out that they were
already fixed in the
> latest SVN as part of an unrelated change made by
Maurizio, two days ago.
>
> The light canvas class is now available in libkdegames
as KGameCanvas.
> KGoldRunner is using the library version already, and
KMahjongg drawing
> code is implementing it right now, as I want to have
very fine control of
> SVG->Pixmap cacheing behavior.
Mauricio could you please describe give a short summary of
this class for 
those who don't know much about it?
Personally I'd like to receive brief answers on questions
like:
1. In what situations this class is a better choice than
QGV?
2. What criteria one should use when choosing QGV or
KGameCanvas?
3. What are the pros/cons of each one?

Thanks in advance,
Dmitry.
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

> Personally I'd like to receive brief answers on
questions like:
> 1. In what situations this class is a better choice
than QGV?

In general, in situations where you are currently using
drawPixmap() and
want a better management of screen redraw, but does not want
to use QGV
structure for one reason of another. Or if you are running
into an issue
with the current QGV feature set, like the lack of ability
to invalidate
partially the background cache, which was hurting
KGoldRunner. This
feature is scheduled for 4.3, btw, Andreas confirmed it to
me during
aKademy.

> 2. What criteria one should use when choosing QGV or
KGameCanvas?

I would say that you should use QGV as your first choice.
Specially if you
do not understand the differences yet. Kpat for example is
using it, and
KReversi as well. IMO you should consider using KGameCanvas
for situations
where a bug or design structure in QGV does not let you
achieve optimal
performance for your game, and you fell you can benefit from
a more direct
QWidget subclass, with only basic functionality. You can
only feel this
usually after at least trying to implement the QGV version.
Like any major
framework it may not fit your needs exactly, and in some
parts of it are
not easily modifiable via subclassing.

> 3. What are the pros/cons of each one?

In a perfect world, you would just use QGV. If you (like me)
however have
just realized that you have spent a lot of time trying to
fit QGV into
your game structure just to draw simple pixmaps, and still
are not getting
optimal performance, then there is no much sense using it,
just go for a
direct QPainter-based solution.

BTW, the KGameCanvas class is still under development. I
found out that
for kdegames needs we need some additions, methods to delete
and remove
members explicitally, for example. Maurizio mentioned using
it in KBoard
with Boost smart pointers, maybe that is the reason why
these are not
readily available.

Regards,
Mauricio Piacentini
Tabuleiro

_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Sunday 01 October 2006 08:14, mauriciotabuleiro.com wrote:
> BTW, the KGameCanvas class is still under development.
I found out that
> for kdegames needs we need some additions, methods to
delete and remove
> members explicitally, for example. Maurizio mentioned
using it in KBoard
> with Boost smart pointers, maybe that is the reason why
these are not
> readily available.
Thanks for explanation!

So the basic line is: use QGV unless you find it doesn't
fits your needs, yes?

Cheers,
Dmitry.
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

Hi,
As main author of the KGameCanvas, i confirm what Mauricio
just said 
Basically KGameCanvas is a very lightweight canvas that may
solve
problems of the QGV (slowness, complexity, etc), but it is
not
optimized to
handle millions of items.
That said, for board games it proved to be very fast.
It is the "thing between a QPainter and the QGV"


> BTW, the KGameCanvas class is still under development.
I found out that
> for kdegames needs we need some additions, methods to
delete and remove
> members explicitally, for example.
Ouch, i think the problem is that the documentation is not
clear enough
about this 
To put an item out and in an abstract canvas, you just have
to call
Item::putInCanvas, doing so the item is removed from the
current canvas,
and if the argument is not NULL it is also inserted in
another canvas.

-- 
Ciao
Maurizio

"Well we all shine on
Like the moon and the stars and the sun" (John Lennon)
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel