KBreakout

Hi all,
I'm not to responsive lately as I've quite some exams to do.
I've started to 
write a breakout clone however (if anybody has a more
interesting name than 
the one in the subject let me know . 
As soon as I think I've got the design right I'll apply for
a KDE account and 
put it in playground. Now I would like your opinion about
some ideas I have:

1. Svg caching.
It takes a bit for most games to start mostly due to
rendering of the svg 
images. I was wondering if it isn't possible to cache the
rendering for the 
last window size used somewhere on disk. Of course resizing
will always 
remain a bit slow. 
The reasoning behind it is that usually users will resize
the game only the 
first time they start it (and maybe not even that if it has
a sane default 
window size). My guess is that more than 80% of the times a
game is started 
it won't be resized.
The problem is how to do it, QGraphicsScene is independent
from the size of 
the View, maybe the View could be passed to the
QGraphicsSceneItems so that 
it can calculate the size of the pixmap to create and
eventually load it from 
the cache instead of rerendering it. But I'm not sure it
would work.
This is also why for now I'm writing the game engine
independent from the 
QGraphicsScene, even it it makes the engine more
complicated.

2. Theming.
I can think of two ways to support theming:
- there is a certain number of objects (including a
background), for each of 
which there should be provided a svg in the theme, if a
certain object isn't 
present there could be a fallback to the default theme for
that object.
- each level or levelset has it's own theme
I personally like the first idea, although the second one
makes the levels 
more different. There could be a combination of the two,
like each level has 
it's own background, but that would cause an inconsistent
look in some 
situations.

Let me know what your opinions are...

cheers,
- Fela
-- 
Hello! I'm a signature virus. Copy me to your signature, ^^
pleeeeease!!!!!!
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Wednesday 20 June 2007, Fela Winkelmolen wrote:
> Hi all,
> I'm not to responsive lately as I've quite some exams
to do. I've started
> to write a breakout clone however (if anybody has a
more interesting name
> than the one in the subject let me know .
> As soon as I think I've got the design right I'll apply
for a KDE account
> and put it in playground. Now I would like your opinion
about some ideas I
> have:
>
> 1. Svg caching.

> The problem is how to do it, QGraphicsScene is
independent from the size of
> the View, maybe the View could be passed to the
QGraphicsSceneItems so that

just set the scene to be the same size as the view and keep
the two in sync 
and you have no problems. this is a cleaner and less
problematic way of 
achieving the same end.

> it can calculate the size of the pixmap to create and
eventually load it
> from the cache instead of rerendering it.

the simple mechanism is to just save out the rendered
pixmaps on exit and load 
from there. this is what we will be doing in Plasma::Svg.
the icon cache that 
rivo is working on as part of his SoC project will come to
good use here as 
well.

> But I'm not sure it would work. 
> This is also why for now I'm writing the game engine
independent from the
> QGraphicsScene, even it it makes the engine more
complicated.

not sure you'll get a good ROI there, but it is your call
=)

> 2. Theming.
> I can think of two ways to support theming:
> - there is a certain number of objects (including a
background), for each
> of which there should be provided a svg in the theme,
if a certain object

instead of loading a huge number of svg's, one per on screen
element, i really 
recommend putting all the elements in one svg and rendering
named elements. 
this makes it easier on artists, is faster to load and
kinder on resources.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1
A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)

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

On Wednesday 20 June 2007, Aaron J. Seigo wrote:
> On Wednesday 20 June 2007, Fela Winkelmolen wrote:
> > Hi all,
> > I'm not to responsive lately as I've quite some
exams to do. I've started
> > to write a breakout clone however (if anybody has
a more interesting name
> > than the one in the subject let me know .
> > As soon as I think I've got the design right I'll
apply for a KDE account
> > and put it in playground. Now I would like your
opinion about some ideas
> > I have:
> >
> > 1. Svg caching.
> >
> > The problem is how to do it, QGraphicsScene is
independent from the size
> > of the View, maybe the View could be passed to the
QGraphicsSceneItems so
> > that
>
> just set the scene to be the same size as the view and
keep the two in sync
> and you have no problems. this is a cleaner and less
problematic way of
> achieving the same end.
>
> > it can calculate the size of the pixmap to create
and eventually load it
> > from the cache instead of rerendering it.
>
> the simple mechanism is to just save out the rendered
pixmaps on exit and
> load from there. this is what we will be doing in
Plasma::Svg. the icon
> cache that rivo is working on as part of his SoC
project will come to good
> use here as well.

I'm not sure I understand exactly how that would work, I'll
have look at the 
icon cache when I'm going to implement caching.

> > But I'm not sure it would work.
> > This is also why for now I'm writing the game
engine independent from the
> > QGraphicsScene, even it it makes the engine more
complicated.
>
> not sure you'll get a good ROI there, but it is your
call =)

Well, now that I know that caching can be archived with
QGraphicsScene I won't 
bother anymore 

> > 2. Theming.
> > I can think of two ways to support theming:
> > - there is a certain number of objects (including
a background), for each
> > of which there should be provided a svg in the
theme, if a certain object
>
> instead of loading a huge number of svg's, one per on
screen element, i
> really recommend putting all tehe elements in one svg
and rendering named
> elements. this makes it easier on artists, is faster to
load and kinder on
> resources.

Yes, actually I knew that, I didn't explain myself to well,
I meant that to 
write a theme you had to make a replacement image for each
element, didn't 
mean svg _file_ =)

cheers,
- Fela
-- 
Hello! I'm a signature virus. Copy me to your signature, ^^
pleeeeease!!!!!!
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Wednesday 20 June 2007, Fela Winkelmolen wrote:
> On Wednesday 20 June 2007, Aaron J. Seigo wrote:
> > On Wednesday 20 June 2007, Fela Winkelmolen
wrote:
> > > it can calculate the size of the pixmap to
create and eventually load
> > > it from the cache instead of rerendering it.
> >
> > the simple mechanism is to just save out the
rendered pixmaps on exit and
> > load from there. this is what we will be doing in
Plasma::Svg. the icon
> > cache that rivo is working on as part of his SoC
project will come to
> > good use here as well.
>
> I'm not sure I understand exactly how that would work,
I'll have look at
> the icon cache when I'm going to implement caching.

the icon cache won't be "ready" for another few
weeks (but the plan is 
hopefully in time for 4.0); i'm also waiting for it with
baited breath 
though.

> Yes, actually I knew that, I didn't explain myself to
well, I meant that to
> write a theme you had to make a replacement image for
each element, didn't
> mean svg _file_ =)

ah, great; nmind me then =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1
A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)

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

On Wednesday 20 June 2007 22:47, Fela Winkelmolen wrote:
> > the simple mechanism is to just save out the
rendered pixmaps on exit and
> > load from there. this is what we will be doing in
Plasma::Svg. the icon
> > cache that rivo is working on as part of his SoC
project will come to
> > good use here as well.
>
> I'm not sure I understand exactly how that would work,
I'll have look at
> the icon cache when I'm going to implement caching.
Well, speaking of kdegames, katomic and klines (which I
happen to maintain ;)) 
already use such kind of caching - but only for background.
Which currently 
takes most of loading & rendering time upon startup.

These games just save rendered background as png at exit
(using overloaded 
KMainWindow::queryClose() method).

If background has high resolution, it may take some time
though. So I added 
even more optimisation: while saving I write dimensions of
last saved 
background to config file, so further saves are done only if
current size of 
bkgnd differs from one in config file. If not - new size is
written to config 
file and background saving takes place.

I save only background, because small and not very complex
elements of svg are 
rendered quite quickly.

Ah, and you can look at the actual code if you have kdegames
checkout or using 
websvn. katomicrenderer.cpp for katomic and renderer.cpp for
klines (actually 
saving code looks quite similar ;)).

Hope this helps 

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

On Thu, 21 Jun 2007 03:05 am, Aaron J. Seigo wrote:
> On Wednesday 20 June 2007, Fela Winkelmolen wrote:
> > This is also why for now I'm writing the game
engine independent from the
> > QGraphicsScene, even it it makes the engine more
complicated.
>
> not sure you'll get a good ROI there, but it is your
call =)
>
At the risk of disagreeing with my fellow saurian, I think
separating
the game engine, especially AI and physics, from the
graphics
would be a good way to go.  It certainly has been with
KGoldrunner.
It also allows the engine to work in a co-ordinate system
that may
be more convenient for designing and coding game logic (i.e.
a
kind of model/view approach).

KGoldrunner has evolved from QPaint-as-you-go in the game
engine,
to QPaint in a paintEvent (Qt1 and Qt2), to QCanvas (Qt3),
to
QGraphicsView (Qt4) and now KGameCanvas, SVG and themes
(KDE4).  All these changes have had little to no impact on
the game
engine, though the graphics classes have had extensive
re-writes
(thanks for ever, Mauricio ).

BTW, I would suggest you do some "materials
testing" on
QGraphicsView (i.e. benchmarks), in case it is not fast
enough
for KBreakout.  Mauricio and I found that QGV was fast
enough
most of the time, but "stumbled" in some
game-levels, especially
where widely separated parts of the view were changing
rapidly.
That was in Qt4.0: QGV has probably been improved now.

The "hiccups" in animation were making the game
unplayable
in the levels affected, so Mauricio, who had ported the game
to
QGV, then converted the graphics to KGameCanvas which is
now in the KDE Games library.

Wishing you every success with your enterprise, Ian W.
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

Fela Winkelmolen wrote:
> (if anybody has a more interesting name than 
> the one in the subject let me know . 

KNoid came to mind, but it doesn't roll off the tongue very
well, and I 
guess arKanoid is asking for trouble .
"Karnoid"? Or even "Karnak"?

Then again, KBreakout follows the tradition of KPoker,
KMahjongg, 
KNibbles, KReversi, KTron, KAsteroids, and so on .

> 2. Theming.
> I can think of two ways to support theming:
> - there is a certain number of objects (including a
background), for each of 
> which there should be provided a svg in the theme, if a
certain object isn't 
> present there could be a fallback to the default theme
for that object.
> - each level or levelset has it's own theme
> I personally like the first idea, although the second
one makes the levels 
> more different. There could be a combination of the
two, like each level has 
> it's own background, but that would cause an
inconsistent look in some 
> situations.

Different backgrounds for various levels is something I've
seen done 
before, but as you say consistency becomes a potential
problem. One 
solution would be to have each /theme/ provide several
backgrounds that 
can then be used in rotation.

-- 
Mathew
(sorry, .sig file is on the other computer)

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

On Thursday 21 June 2007, Ian Wadham wrote:
> On Thu, 21 Jun 2007 03:05 am, Aaron J. Seigo wrote:
> > On Wednesday 20 June 2007, Fela Winkelmolen
wrote:
> > > This is also why for now I'm writing the game
engine independent from
> > > the QGraphicsScene, even it it makes the
engine more complicated.
> >
> > not sure you'll get a good ROI there, but it is
your call =)
>
> At the risk of disagreeing with my fellow saurian, I
think separating
> the game engine, especially AI and physics, from the
graphics
> would be a good way to go.  It certainly has been with
KGoldrunner.
> It also allows the engine to work in a co-ordinate
system that may
> be more convenient for designing and coding game logic
(i.e. a
> kind of model/view approach).

Ok, you made me doubt. It would make the game a lot easier
to write using 
QGraphicsSceneItems directly in the GameEngine, and I don't
think 
QGraphicsScene will become obsolete anytime soon. But I'm a
bit concerned 
about the performance, a simple game like this really
shouldn't really use 
more than 5% of the cpu on a modern pc... I did a quick test
adding 10 balls, 
and it became unplayable, but that is likely caused by my
own code. I think I 
will do some more performance testing and than decide.

> [...]
> Wishing you every success with your enterprise, Ian W.

thanks =)

- fela

-- 
Hello! I'm a signature virus. Copy me to your signature, ^^
pleeeeease!!!!!!
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Sat, 23 Jun 2007 12:02 am, Fela Winkelmolen wrote:
> Ok, you made me doubt. It would make the game a lot
easier to write using
> QGraphicsSceneItems directly in the GameEngine, and I
don't think
> QGraphicsScene will become obsolete anytime soon. But
I'm a bit concerned
> about the performance, a simple game like this really
shouldn't really use
> more than 5% of the cpu on a modern pc... I did a quick
test adding 10
> balls, and it became unplayable, but that is likely
caused by my own code.
> I think I will do some more performance testing and
than decide.
>
Two suggestions.  If you "export
QT_FLUSH_PAINT=1", you get yellow
flashes that show you what QGraphicsView is doing (i.e. how
much of
the view is being re-drawn as the animation proceeds).  Also
Mauricio
implemented two very small subclasses, for sprites and the
playfield,
when using QGV, and that made it easier for him to switch
to
KGameCanvas IIRC.

All the best, Ian W.
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel