[Kde-games-devel] Helping with KGameRenderer porting

[Stefan Majewsky]

On Saturday 07 August 2010 04:09:39 Brian Croom wrote:
> I've just joined
this list and am responding to Stefan Majewsky's blog
>
posting<http://majewsky.wordpress.com/2010/08/06/junior-job-kgamerenderer-p

> orting/>(seen on Planet KDE) about a "junior job" involving porting games
>
to use KGameRenderer etc. 

Woohoo, my plan worked! Welcome to kdegames!

>
I have been coding with C++ for a long time and consider myself proficient
>
with the language, but have no experience to speak of with Qt. I'd like to
>
learn! 

Some experience with Qt would be good. The documentation [1]
includes excellent tutorials.

> I would appreciate pointers about getting a
development environment
> set up. How much of the KDE source tree will I
need to check out in order
> to build the KDE games?
>
> My development
system is currently running Ubuntu
> 10.04; can I use the Qt development
packages from the repos (4.6.2) or do
> I need something more recent? I
don't have any KDE packages installed on
> here currently but I would still
like to keep development stuff
> self-contained, i.e. not installed into
/usr and such. How difficult is
> that going to be?

Qt 4.6 is the current
requirement for KDE trunk. (We won't rely on Qt 4.7 before it's released.)
You basically need two KDE modules: kdelibs (of course) and kdegames. For
kdelibs, it will suffice to use the version from KDE SC 4.5, which should be
available for Kubuntu (at least the current RC2, the final version is due
Wednesday).

So if you have kdelibs 4.5 installed already, you will only
need to checkout the kdegames source tree [2][3], which contains the games
themselves and the libkdegames in which you find the KGameRenderer classes.
General information about setting up a self-contained KDE development
environment is in our techbase wiki at [4]. If you have trouble following
these descriptions, you can also find help on kde-devel at kde.org or on
Freenode IRC (#kdegames).

> If someone could provide a synopsis of what the
new KGameRenderer
> class(es?) is/are for and the reasons for the porting,
that would be
> helpful as well.

A basic explanation is in a previous
blogpost of mine. [5] The basic reason is that we have about 30 games in the
module which all implement their own SVG rendering and caching classes. This
brings all the usual problems of bloat: fixing a bug or implementing a
clever caching strategy in one app won't benefit the others, 30
implementations means a 30-fold higher chance of bugs, etc. Add to that that
we are currently quite low on manpower, and you'll understand why I try to
reduce the codesize by sharing code via libraries.

For more reference on
KGameRenderer is and how to use it, have a look at the API documentation [6]
or at the code of KDiamond, Killbots and KSame, which have already been
ported.

> I'm looking forward to working with you!

So do I! Please let me
know if you have any further questions.

Greetings
Stefan

[1]
http://qt.nokia.com/doc/4.6/
[2]
svn://anonsvn.kde.org/home/kde/trunk/KDE/kdegames/
[3]
http://websvn.kde.org/trunk/KDE/kdegames/
[4]
http://techbase.kde.org/Getting_Started/Build/KDE4
[5]
http://majewsky.wordpress.com/2010/06/13/kgamerenderer-caching-on-multiple-l
evels/
[6]
http://api.kde.org/4.x-api/kdegames-apidocs/libkdegames/html/classKGameRende
rer.html