Comments on: Putting KGameCanvas to sleep. Forever. http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/ Programming, KDE and more Sat, 28 Nov 2009 18:10:07 +0000 http://wordpress.com/ hourly 1 By: Adriano http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-334 Adriano Wed, 30 Apr 2008 15:06:42 +0000 http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-334 Hi Maurizio, I've already made all possible optmizations in QGV. (Index, Render Mode, Clip...). It has the worst performance among all my choices, and it's very bloat. And neither QGV or kgamecanvas has all support for what I need (Edje support), so I would have to change the internal code anyway. It would be better if this core engine was lightweight and easy to mantain, and Trolltech license is very restrictive. Hi Maurizio,

I’ve already made all possible optmizations in QGV. (Index, Render Mode, Clip…). It has the worst performance among all my choices, and it’s very bloat. And neither QGV or kgamecanvas has all support for what I need (Edje support), so I would have to change the internal code anyway. It would be better if this core engine was lightweight and easy to mantain, and Trolltech license is very restrictive.

]]> By: Maurizio http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-333 Maurizio Wed, 30 Apr 2008 14:22:41 +0000 http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-333 Consider that KGameCanvas is now deprecated, instead look for the correct settings for QGV to make it fast (correct cache, clip, etc). Regards! Consider that KGameCanvas is now deprecated, instead look for the correct settings for QGV to make it fast (correct cache, clip, etc).
Regards!

]]> By: Adriano http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-332 Adriano Wed, 30 Apr 2008 01:12:51 +0000 http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-332 Hi, I made some benchmarks with KGameCanvas and QGV (with all optimization flags and Qt4.3) and KGameCanvas demonstrates to be much more faster. I'm developing for Nokia n800 devices, and QGV suffers to animate few sprites in it (with 5 sprites fps goes down to 8) while KGameCanvas handles 50 sprites with 20-30 fps. I made a program like 'expedite' to test and it was faster than Evas! Running this test with 128 images (overlapping each other) on the device the result was: QGV (8 fps), Evas (36 fps), KGameCanvas (55 fps). The only problem I'm facing is that KGameCanvas seems to flick more than QGV and the animations sometimes are not linear (small freezes). Do you know if there is some way to reduce flicker, changing part of KGameCanvas code? I thought it could be the repaint method, but changing to update didn't solve. I would like to use KGameCanvas because its perfect for what I need due to its lightweight engine. QGV is not light enough to run on these kind of devices yet. Hi, I made some benchmarks with KGameCanvas and QGV (with all optimization flags and Qt4.3) and KGameCanvas demonstrates to be much more faster. I’m developing for Nokia n800 devices, and QGV suffers to animate few sprites in it (with 5 sprites fps goes down to 8) while KGameCanvas handles 50 sprites with 20-30 fps. I made a program like ‘expedite’ to test and it was faster than Evas! Running this test with 128 images (overlapping each other) on the device the result was: QGV (8 fps), Evas (36 fps), KGameCanvas (55 fps).
The only problem I’m facing is that KGameCanvas seems to flick more than QGV and the animations sometimes are not linear (small freezes).

Do you know if there is some way to reduce flicker, changing part of KGameCanvas code? I thought it could be the repaint method, but changing to update didn’t solve.

I would like to use KGameCanvas because its perfect for what I need due to its lightweight engine. QGV is not light enough to run on these kind of devices yet.

]]> By: Maurizio http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-32 Maurizio Tue, 31 Jul 2007 19:31:16 +0000 http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-32 Thanks for your comment Mauricio! In facts, i don't think that I did a bad thing writing it, and did it precisely to make work the old kboard code with Qt4. And before putting it definitively to sleep, we will still have to see if Tagua survives the port too (and not only KGoldRunner) :) Thanks for your comment Mauricio!
In facts, i don’t think that I did a bad thing writing it, and did it precisely to make work the old kboard code with Qt4.
And before putting it definitively to sleep, we will still have to see if Tagua survives the port too (and not only KGoldRunner) :)

]]> By: Mauricio Piacentini http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-30 Mauricio Piacentini Tue, 31 Jul 2007 14:11:22 +0000 http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-forever/#comment-30 I believe that if it were not for KGameCanvas we would have not triggered lots of thinking and experimentation about issues that existed in previous versions of QGV. You are correct that with version 4.3 most of these have been addressed, but several games (KGoldRunner, KMahjongg) would not have been ported to Qt4 if KGameCanvas did not exist 12 months ago. So thanks for writing it, and contributing it to libkdegames. And before you put it to sleep, let us see if KGoldRunner specially survives a re-conversion to QGV, just to be on the safe side :) I believe that if it were not for KGameCanvas we would have not triggered lots of thinking and experimentation about issues that existed in previous versions of QGV. You are correct that with version 4.3 most of these have been addressed, but several games (KGoldRunner, KMahjongg) would not have been ported to Qt4 if KGameCanvas did not exist 12 months ago.
So thanks for writing it, and contributing it to libkdegames. And before you put it to sleep, let us see if KGoldRunner specially survives a re-conversion to QGV, just to be on the safe side :)

]]>