Tomasz Boczkowski wrote:
> The second solution seems to be most resonable, but
doesn't the usage of
> various canvas frameworks in one kdegames package lead
to inconsistency?
I don't think so. Even before Qt4 there were some games that
used
QCanvas, while others used QPainter directly, and still
others that had
their own sprite/dirty rect routines. The main benefit of
using QGV in
theory is to offset development/maintenance costs to TT,
imo.
KGameCanvas is very light, and it is already in libkdegames
anyway, as
it is used by more than one game. So there is no extra
weight added to
KBounce specifically, either with QGV or KGameCanvas.
In the future, of course, it could be good for new authors
and
maintainers if all games shared the same implementation, but
I do not
see it happening any time soon. Even using QPainter directly
is the best
approach for some apps, as you know, and there is no sense
in forcing
QGV implementations of these apps. And ultimately all of
these solutions
end up using QPainter calls anyway, right?
Of course, using other drawing backends (SDL or GTK) is
probably too
much, but I do not see any demand for this.
Regards,
Mauricio Piacentini
_______________________________________________
kde-games-devel mailing list
kde-games-devel kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel
|
