[Kde-games-devel] GSoC 2012 - Porting Games to QML

[Ian Wadham]

On 04/03/2012, at 10:42 AM, Mehmet Emre wrote:
> 2012/3/4 Ian Wadham <iandw.au at gmail.com>:
>> Your next step would be to show us what you can do, e.g. by submitting
>> a patch to fix a bug in a game or add a small feature.
> 
> I can port a game to QGV to show what I'm capable of. I can either
> submit a patch
> or create a fork of the game and submit the fork.

That would indeed be impressive!  Remember, though, that you have only a
few weeks before you put in your GSoC proposal.  Use your time carefully.
And pick one of the smaller games that is using KGameCanvas.

Avoid KGoldrunner.  Its graphics, rendering and cacheing have been re-written
many times and several people were involved.  It was one of the first games
to be converted to Qt 4 and KDE 4 --- and it shows…  I can say that.  I am
the maintainer … ;-)

A patch would be the way to go.  KDE has a Reviewboard system for
submitting and reviewing patches before they are committed to SVN.
There is a thread in the last week or so in our mail archives that shows
how the process goes.  There is probably a Techbase page on it.

>> Please note that there are engineering concerns with converting some of the
>> games from KGameCanvas to QGraphicsView and from QGraphicsView to QML.
>> 
>> They concern the speed and consistency of animation in QGraphicsView and
>> possibly in QML.  Some games require continuous quick animation, such as
>> KGoldrunner.  In past versions, QGV was fast enough most of the time, but
>> had annoying cases in which the animation would hiccup (freeze up) at
>> random for several tenths of a second, making the game unplayable.  That
>> is why we switched to KGameCanvas.  Maybe QGV is nowadays fast enough
>> and consistent enough, but …
>> 
>> ... there is a risk that switching from one graphics stack to another could
>> introduce subtle, hard to diagnose, bugs into a currently working game.
>> 
>> There is less risk of that if you only change the code that renders SVG and
>> caches pixmaps, which is largely in the startup/initialisation of games.  See
>> the warnings in http://techbase.kde.org/Projects/Games/Porting ...
> 
> Then it might be hard to port a game properly, to prevent fails in performance I
> will firstly only change the rendering code and if it hiccups then I
> try to solve
> the hiccups without touching the graphic stack but if it still fails
> then I might
> have to change the graphics stack bu I'll try to avoid that as much as I can.

It should not hiccup during rendering and cacheing using KGameRenderer.

The main problem QGV had with maintaining the speed of fast animations
was when there were several movements happening in different parts of the
viewport.  QGV might then decide to repaint the entire containing rectangle
and that would take more than the 20-50 msec of real wall-clock time available.

That kind of thing is quite difficult to test because it depends on the configuration
of the game-level, the human player's moves and the built-in gameplay, all at once.
I expect Trolltech have solved that problem now --- we gave them lots of feedback,
which was appreciated --- but who knows what other problems lie hidden?

>> I appreciate your "kill two birds with one stone" idea, Mehmet, but please
>> beware of biting off more than you can chew.
> 
> By taking your advice I'll participate GSoC only for porting from KGameCanvas to
> QGV and later on (after properly finishing the porting as project i.e.
> after this
> summer) I may try to move the games I moved to QGV to QML.

That would be the way to go.  Except we do not need more than one game in QML.

Conversion to KGameRenderer and possibly QGV is a tidying-up exercise, to
avoid having many games doing similar things in different ways.

The objective of the QML exercise is different, IIUC.  We wish to gain experience in
writing (new) games in QML and find out what strengths and weaknesses there are
and what new KDE Games library features might be required for use with QML.

Cheers, Ian W.