New Mazes game in KGoldrunner

Hi guys,

I have just committed the latest set of KGoldrunner levels from
Steve Mann, who previously contributed the Count and Curse
of the Mummy levels.  This time the theme is mazes and the
levels are named after dwarfs from myth and story.  These
great new levels are for release with KDE 4.4 in early February.

The KGoldrunner grid of 28x20 squares is not much space in
which to construct a conventional maze of reasonable difficulty,
but when you add enemies, false bricks, hidden ladders and quirky
Traditional rules, it can become surprisingly difficult to find your
way through.  I have had such a lot of fun "testing"!

There are 37 levels in the Mazes set.  Enjoy!

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

[Arturo Silva]

Ian Wadham wrote:

> Hi guys,
>
> I have just committed the latest set of KGoldrunner levels from
> Steve Mann, who previously contributed the Count and Curse
> of the Mummy levels.  This time the theme is mazes and the
> levels are named after dwarfs from myth and story.  These
> great new levels are for release with KDE 4.4 in early February.
>
> The KGoldrunner grid of 28x20 squares is not much space in
> which to construct a conventional maze of reasonable difficulty,
> but when you add enemies, false bricks, hidden ladders and quirky
> Traditional rules, it can become surprisingly difficult to find your
> way through.  I have had such a lot of fun "testing"!
>
> There are 37 levels in the Mazes set.  Enjoy!
>
> All the best, Ian W.

Thank you very much!  This is something else I will be looking forward
to testing out.  :)
But since these are levels and not code per se, I'm assuming we have a
little more time to review these (in other words, they wouldn't be
impacted by the feature freeze)?


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

On Tue, 13 Oct 2009 11:10:56 pm Arturo Silva wrote:

> Ian Wadham wrote:
> > Hi guys,
> >
> > I have just committed the latest set of KGoldrunner levels from
> > Steve Mann, who previously contributed the Count and Curse
> > of the Mummy levels.  This time the theme is mazes and the
> > levels are named after dwarfs from myth and story.  These
> > great new levels are for release with KDE 4.4 in early February.
> >
> > The KGoldrunner grid of 28x20 squares is not much space in
> > which to construct a conventional maze of reasonable difficulty,
> > but when you add enemies, false bricks, hidden ladders and quirky
> > Traditional rules, it can become surprisingly difficult to find your
> > way through.  I have had such a lot of fun "testing"!
> >
> > There are 37 levels in the Mazes set.  Enjoy!
> >
> > All the best, Ian W.
>
> Thank you very much!  This is something else I will be looking forward
> to testing out.  :)
> But since these are levels and not code per se, I'm assuming we have a
> little more time to review these (in other words, they wouldn't be
> impacted by the feature freeze)?
>

I am regarding them as a "feature" anyway and have posted them in
http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan#kdegames

The levels all work on my machine and Steve Mann's, but it is possible,
due to subtle timing differences, that one of them will not work on some
platform somewhere ... as with code.  So the more exposure they get
before release, the better.  However, I am not suggesting everyone has
to "test" all the levels ... it has taken Steve and me several days ... :-)

More importantly, the levels contain hint-texts and those have to be in the
hands of translators before the Message Freeze, aka "string freeze".  And
it is not unknown for there to be typos and translation difficulties in the
hints, even the odd bit of non-US English ... :-)

"Center"?  Ugh!!!  Centre, centre!  Unfortunately, KDE insists on US English,
so "center" it has to be ... :-(

All the best, Ian W.
Proudly English and Australian.
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Arturo Silva]

==========================================
 Ian Wadham wrote:
==========================================

> I am regarding them as a "feature" anyway and have posted them in
> http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan#kdegames
>
> The levels all work on my machine and Steve Mann's, but it is possible,
> due to subtle timing differences, that one of them will not work on some
> platform somewhere ... as with code.  So the more exposure they get
> before release, the better.  However, I am not suggesting everyone has
> to "test" all the levels ... it has taken Steve and me several days ... :-)
>
> More importantly, the levels contain hint-texts and those have to be in the
> hands of translators before the Message Freeze, aka "string freeze".  And
> it is not unknown for there to be typos and translation difficulties in the
> hints, even the odd bit of non-US English ... :-)
>
> "Center"?  Ugh!!!  Centre, centre!  Unfortunately, KDE insists on US English,
> so "center" it has to be ... :-(

LOL, well I've always been partial to "centre" and "colour" myself, so
I can sorta feel your pain. ^^;

Even after I'm done with Granatier, I do have a few things to do with
Palapeli and some Oxygen icons.  However, I do like KGoldRunner and
appreciate the efforts to improve it even further, so I'll book some
time for it for sure before the end of the month.  ^__~


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

On Wed, 14 Oct 2009 9:22:13 am Arturo Silva wrote:
>  Ian Wadham wrote:
> > "Center"?  Ugh!!!  Centre, centre!  Unfortunately, KDE insists on US
> > English, so "center" it has to be ... :-(
>
> LOL, well I've always been partial to "centre" and "colour" myself, so
> I can sorta feel your pain. ^^;
>
In England I must walk on the pavement, but in Australia I get, "Strewth,
don't give us yer Pommy talk here!  It's 'footpath' --- next to the nature
strip!"[1]  And in the USA, if I walk on the pavement, I will get flattened
by a car!  It's 'sidewalk' over there.  Language is a survival matter ... :-)

> Even after I'm done with Granatier, I do have a few things to do with
> Palapeli and some Oxygen icons.  However, I do like KGoldRunner and
> appreciate the efforts to improve it even further, so I'll book some
> time for it for sure before the end of the month.  ^__~
>
Thanks, Arturo!  I'm glad we are keeping you busy at KDE Games ... :-)

Cheers, Ian W.

[1] Nature strip - nothing to do with nudism!  It is a strip of grass and
trees between the footpath and the road.


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

[Arturo Silva]

Ian Wadham wrote:
>
> In England I must walk on the pavement, but in Australia I get, "Strewth,
> don't give us yer Pommy talk here!  It's 'footpath' --- next to the nature
> strip!"[1]  And in the USA, if I walk on the pavement, I will get flattened
> by a car!  It's 'sidewalk' over there.  Language is a survival matter ... :-)
>
>>
> Thanks, Arturo!  I'm glad we are keeping you busy at KDE Games ... :-)
>

LOL on both accounts.  Thank YOU guys for having me, it's been an
interesting experience thus far.  Taking good notes, as I'd like to
work on my own game some day. ^^



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

Ian Wadham skreiv:

> :-)
>
> "Center"?  Ugh!!!  Centre, centre!  Unfortunately, KDE insists on US
> English, so "center" it has to be ... :-(

Fortunately, KDE has a (very complete) British English translation.

--
Karl Ove Hufthammer
E-mail: karl@...
Jabber: huftis@...

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

[Luciano Montanaro]

On martedì 13 ottobre 2009, Ian Wadham wrote:
> Hi guys,
>
> I have just committed the latest set of KGoldrunner levels from
> Steve Mann, who previously contributed the Count and Curse
> of the Mummy levels.  This time the theme is mazes and the
> levels are named after dwarfs from myth and story.  These
> great new levels are for release with KDE 4.4 in early February.

That's really great to see, Ian, it seems we actually have a "community" of
contents contributors. Although a small one, for now.

Have you anything else in store for KGoldrunner?

I've been at the Gluon sprint earlier this week, and they have in store a few
things we could put to use in KGoldrunner when they are finalized.
The KAL (Audio library, based onOpenAL) would be a nice and easy alternative
to phonon, for example. And it may be a nice way to help out the great Gluon
crew to find bugs or missing features. I'll try to work on this and send
patches; they need not be integrated in KGoldrunner until after the 4.4
release, of course.

Luciano

--
Luciano Montanaro //
                \X/ mikelima@...
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Sun, 18 Oct 2009 12:45:50 am Luciano Montanaro wrote:

Hey, long time no see, Luciano! ... :-)

> On martedì 13 ottobre 2009, Ian Wadham wrote:
> > I have just committed the latest set of KGoldrunner levels from
> > Steve Mann, who previously contributed the Count and Curse
> > of the Mummy levels.  This time the theme is mazes and the
> > levels are named after dwarfs from myth and story.  These
> > great new levels are for release with KDE 4.4 in early February.
>
> That's really great to see, Ian, it seems we actually have a "community" of
> contents contributors. Although a small one, for now.
>

Very small ... just Steve Mann, who contributed the last 3 games ... :-)

> Have you anything else in store for KGoldrunner?
>
Just updated kdegames/kgoldrunner/TODO and committed it.  I am not sure
how much time I will have between now and Message Freeze, so I have
not put anything much on the KDE 4.4 Feature Plan yet.

One thing will be some major changes to KGrTheme and KGrCanvas, to
avoid having to do a SVG load every time KGoldrunner runs.  It will now
load a theme only if it was never loaded before or if a newly-required size
is not in the cache and will have to be rendered.  I expect to commit this
change in the next few days.

Actually I have had another major project lately: building a wooden digger
machine for my grandson's sandpit.  Real deadline: his third birthday, a week
or two ago.  He is delighted with it ... :-)

Also I have been playing around with a rewrite of KSokoban.  I have a
toy version running, but with just circles and squares in the graphics.
When it is reasonably playable, I will put it in playground/games, maybe
with a view to a KDE 4.5 release.

> I've been at the Gluon sprint earlier this week, and they have in store a
> few things we could put to use in KGoldrunner when they are finalized. The
> KAL (Audio library, based onOpenAL) would be a nice and easy alternative to
> phonon, for example. And it may be a nice way to help out the great Gluon
> crew to find bugs or missing features. I'll try to work on this and send
> patches; they need not be integrated in KGoldrunner until after the 4.4
> release, of course.
>
Hmmmm ... I was dubious of the reality of Gluon earlier on in this list, with
its paucity of information and mysterious "Dr IDK" in the background, but
if you have seen it up close and can vouch for it, Luciano, I'll go with that.
Take note that I reorganized KGoldrunner sound code a bit for KDE 4.3.

I did find info about OpenAL and it seemed to be a much better basis for
games sounds than Xine, etc.  However I am worried about introducing
dependencies outside the regular kdelibs, libkdegames, Qt set.  That
could adversely affect future compilation, building and distribution of
KGoldrunner itself, for the gain of just a little sound quality.

Why is there not an OpenAL backend for Phonon?  Is the world of sound
in KDE and Qt limited to notifications and Amarok tracks?  On Apple, for
example, my son has a fully-fledged music composition and mixing studio,
though it is not FOSS.  He used it when composing the KGoldrunner sounds.

Cheers, Ian W.





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

On Sat, 17 Oct 2009 8:44:53 pm Karl Ove Hufthammer wrote:
> Ian Wadham skreiv:
> > "Center"?  Ugh!!!  Centre, centre!  Unfortunately, KDE insists on US
> > English, so "center" it has to be ... :-(
>
> Fortunately, KDE has a (very complete) British English translation.
>
Yes, I know, but I do not use en_GB, a) because I am a KDE developer
and b) because I am in Australia and there is no en_AU in KDE, nor
in OpenSuSE.  On balance, en_AU is perhaps closer to en_US than
en_GB, an after-effect no doubt of World War II, which may also
account for en_US being used in KDE.

I do worry however about the relentless march of American culture
and English language throughout the world, powered by Hollywood
and big business.  Even successful Australian actors have to adopt
American accents when they appear in American movies and TV
shows[1].  There is a special school they go to to learn the accent!

Cheers, Ian W.

[1] Nicole Kidman, Cate Blanchett, Russell Crowe, Anthony LaPaglia,
Heath Ledger, Hugh Jackman and even Errol Flynn, to name a few.

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

[Luciano Montanaro]

On domenica 18 ottobre 2009, Ian Wadham wrote:
> On Sun, 18 Oct 2009 12:45:50 am Luciano Montanaro wrote:
>
> Hey, long time no see, Luciano! ... :-)

Yes, sorry about that, I've been very busy at work up to july, and then
vacation, etc. you know...
But I've kept an eye on KGoldrunner, KDE 4.3 version is very nice.

> >
> > That's really great to see, Ian, it seems we actually have a "community"
> > of contents contributors. Although a small one, for now.
>
> Very small ... just Steve Mann, who contributed the last 3 games ... :-)
>

Yes, I noticed. Let's hope it will grow... But still, it means we have at
least an happy player. Did you ask him to comment on our development plan, and
see if there are features he's missing, in the editor or in the game?
I'm not sure if he may want to join in the mailing list, but the point of view
of a "modder" could be interesting to hear also by other game developers.

> > Have you anything else in store for KGoldrunner?
>
> Just updated kdegames/kgoldrunner/TODO and committed it.  I am not sure
> how much time I will have between now and Message Freeze, so I have
> not put anything much on the KDE 4.4 Feature Plan yet.
>
> One thing will be some major changes to KGrTheme and KGrCanvas, to
> avoid having to do a SVG load every time KGoldrunner runs.  It will now
> load a theme only if it was never loaded before or if a newly-required size
> is not in the cache and will have to be rendered.  I expect to commit this
> change in the next few days.
>

Oh, yes, we still load the svg file on startup. I tend to use my simple
themes, so I do not notice that much, but of course, we should load the svg
only when needed.
 
> Actually I have had another major project lately: building a wooden digger
> machine for my grandson's sandpit.  Real deadline: his third birthday, a
>  week or two ago.  He is delighted with it ... :-)
>

Of course, life is not only programming. :)

> Also I have been playing around with a rewrite of KSokoban.  I have a
> toy version running, but with just circles and squares in the graphics.
> When it is reasonably playable, I will put it in playground/games, maybe
> with a view to a KDE 4.5 release.
>

Another nice game, and anothergame where user made content cam keep the game
going on and on...
Did you manage to reuse any code from katomic, by chance? The games are
similar, except for the game logic itself.

> > I've been at the Gluon sprint earlier this week, and they have in store a
> > few things we could put to use in KGoldrunner when they are finalized.
> > The KAL (Audio library, based onOpenAL) would be a nice and easy
> > alternative to phonon, for example. And it may be a nice way to help out
> > the great Gluon crew to find bugs or missing features. I'll try to work
> > on this and send patches; they need not be integrated in KGoldrunner
> > until after the 4.4 release, of course.
>
> Hmmmm ... I was dubious of the reality of Gluon earlier on in this list,
>  with its paucity of information and mysterious "Dr IDK" in the background,
>  but if you have seen it up close and can vouch for it, Luciano, I'll go
>  with that. Take note that I reorganized KGoldrunner sound code a bit for
>  KDE 4.3.
>

Well, the libraries are in various states of development, of course, but they
are already usable. The blok game is the testing ground for all of the
components, and it's quite fun to play...
You can have a look at what it is here:
 http://www.youtube.com/watch?v=whxl7JTixc8

> I did find info about OpenAL and it seemed to be a much better basis for
> games sounds than Xine, etc.  However I am worried about introducing
> dependencies outside the regular kdelibs, libkdegames, Qt set.  That
> could adversely affect future compilation, building and distribution of
> KGoldrunner itself, for the gain of just a little sound quality.
>

OpenAL is an external dependency, but a "shallow" one - it does not in itself
require other larger libraries that are not already needed for KDE. And it's
available on most (probably all) the platforms we have ported KDE to, so I
think it is not an unreasonable dependency. But anyway, I'm planning to keep
the current phonon code there, and add a runtime check for KAL. If it's there,
I'll dlopen KAL and use it, otherwise I'll use Phonon.

> Why is there not an OpenAL backend for Phonon?

Because OpenAL is a low level library (it does not really understands anything
but PCM, by itself) while Phonon deals mainly with high level, stuff- it has
no way to deal with sample buffers directly.
 
> Is the world of sound
> in KDE and Qt limited to notifications and Amarok tracks?

It looks so, at the moment. I'm not sure of the roadmap for phonon either, Qt
4.6 introduces a new lower level api QtMultimedia API that has support with
some of the things we need in games, and bypasses Phonon completely. There has
been some discussion about that at the Sprint and at the conference, but I
don't know what will come of it at the end.

> On Apple, for
> example, my son has a fully-fledged music composition and mixing studio,
> though it is not FOSS.  He used it when composing the KGoldrunner sounds.

I've never looked at a Mac too closely in the last ten years, but I'm sure
there is good software for that. And the audio stack in Linux is a mess...
I hope we'll not add to that, though.

Tschüß,
Luciano


--
Luciano Montanaro //
                \X/ mikelima@...
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Sun, 18 Oct 2009 9:03:43 pm Luciano Montanaro wrote:

> On domenica 18 ottobre 2009, Ian Wadham wrote:
> > ... just Steve Mann, who contributed the last 3 games ... :-)
>
> Yes, I noticed. Let's hope it will grow... But still, it means we have at
> least a happy player. Did you ask him to comment on our development plan,
> and see if there are features he's missing, in the editor or in the game?
> I'm not sure if he may want to join in the mailing list, but the point of
> view of a "modder" could be interesting to hear also by other game
> developers.
>

Steve is an Associate Professor of Computer Graphics who plays
KGoldrunner and composes levels in his spare time, as a form of
relaxation.  I have had several discussions with him in the last year
or so.  He is happy with the features and gameplay in general and
is rather an expert player, I would say.  I cannot wait to see his
recordings of levels when he upgrades to KDE 4.3, probably
around Christmas vacation time.

He was not very happy with the KDE 4 version at first.  The graphics
tended to make the gameplay harder to follow --- a problem I also
have had, so I usually use the Nostalgia theme when I really want to
"strip for action" and tackle a really difficult level, but I use the Egypt
theme a lot and so does he.  KDE 4 and the Egypt theme grew on him
after a while and you can see the results in his "Curse of the Mummy"
game.

> Tschüß, Luciano

Have you been drinking too much German beer, Luciano? ... :-)

Anyway, thanks for all your interesting comments on Gluon, OpenAL,
sound, etc.  I have taken them to heart.

Ciao, Ian W.


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

[Luciano Montanaro]

Hi all,

I know we are now in feature freeze, but we can discuss our plan for the
future, don't we?

I have some issue with the way theming is implemented in KGoldrunner, we
discussed it at KDE 4.0 time, but I think we are again at a bottleneck.

I'm a bit sad that the only themes for KGoldRunner are from people on this
list, and while that may mean there is little interst in the game, it may also
mean it is too hard to make or modify themes. Furthermore, if Ian proceeds
with the plan to implement XScavenger levels, we'll need a new kind of enemy,
and a new treasure type (plus a few animations here and there).

Since all actors in kgoldrunner use the same animation frames, and it's much
easier to change just the reference body parts of an actor compared to the
animation frames, I think it would be easier to have users contribute their
own theming.

Another point: Ian said earlier that we have performance problems in theme
loading: the theme graphics have to be loaded from disk on startup and parsed,
which takes some time. The more complex the theme, the slower the game
startup. That's not good...

A solution could be improving caching, and not loading the svg file unless the
window size changes and the tiles need to be regenerated. But this still means
each window resize could involve along pause, before everything is rendered
again.


but I think we can improve loading speed, theme authoring and theming
possibilities just by splitting up the theme files more. We could keep the
current themes as they are, ad add a new theme version for these new themes,
to keep the ability to load current themes, or we could simply convert them
and use the new format. Either option should not be too hard to implement.

Here is the structure I propose to implement for these new themes:

In the theme folder, there will be the following elements:
 * background-<n>.svg -- background variant <n>. The game will cycle through
the avaliable backgrounds.
 * tiles-<n>.svg      -- tiles variant n. Cycling, as above. It is possible to                
                         have a different number of tile set than backgrounds
 * hero.svg           -- The hero graphic. We don't need more than one --
                         unless we implement multiplayer games
 * enemy-<n>.svg      -- The enemy graphics variant <n>.
 * gold-enemy-<n>.svg -- The enemy carrying gold.
 * monster-<n>.svg    -- Monster graphics variant <n> (for XScavenger games)

The hero, enemy and gold-enemy have exactly the same frames, and could be
swapped just by renaming them. We could have, for example, the Hero Mummy
chased by Evil Adventurers!

And we could make a monster just by copying over the mummy file, and changing
the head to an Anubi mask...

MyTheme.desktop should be changed in this way:

Add a VersionNumber, so the theming engine can change loading strategy
Remove the Set and Actors fields, and replace them with a ThemeFolder field
where the theme element are stored.
Maybe it would be useful to add
NumberOfBackgrounds=n
NumberOfTilesets=n
NumberOfEnemySets=n
and
NumberOfMonsterSets=n

It is not needed -- the game could simply try to load a new set, and if it is
not available, wrap the counter around, but it may be useful to know if it's
possible to cache the theme graphics.

The startup time reduction would resulting mainly from the fact that we do not
load a gigantic svg file with many backgrounds, but only the background needed
at the moment. And maybe we could use threads to load all the components in
parallel. Even on single core machines, this should help.

Luciano


--
Luciano Montanaro //
                \X/ mikelima@...
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Sat, Oct 24, 2009 at 06:41, Luciano Montanaro wrote:

> Another point: Ian said earlier that we have performance problems in theme
> loading: the theme graphics have to be loaded from disk on startup and parsed,
> which takes some time. The more complex the theme, the slower the game
> startup. That's not good...
>
> A solution could be improving caching, and not loading the svg file unless the
> window size changes and the tiles need to be regenerated. But this still means
> each window resize could involve along pause, before everything is rendered
> again.
>
> ...snip...
>
> The startup time reduction would resulting mainly from the fact that we do not
> load a gigantic svg file with many backgrounds, but only the background needed
> at the moment. And maybe we could use threads to load all the components in
> parallel. Even on single core machines, this should help.

Hey Luciano,

As far as threaded rendering and loading goes, you might want to have
a look at KCardCache and how it's used in KPat. In the run up to
KDE4.3, we noticed that the load times had gotten pretty bad. Sean had
just introduced the lovely Ancient Egyptians card deck, which while
beautiful, was significantly larger and more complex than any deck. He
later made some optimisation and brought size down, but it was still
obvious that we needed smarter card rendering.

At first I delayed loading the SVG and rendering of cards until we
came across a pixmap that wasn't in the cache. This help with start up
performance, but the first time an unrendered card was flipped over,
things ground to a halt while the file was loaded into the
QSvgRenderer and the pixmap was rendered. This was worse than the
delay at startup (even though it was a bit shorter) because it felt
like a much more significant interuption. I was also surprise at how
much time it took to just load the SVG into the QSvgRenderer,
especially for complex decks.

In the end, I (with Albert's assistance) fixed up and heavily modified
the threading loading in KCardCache. How things work now is:
1. KPat tells KCardCache which card deck/size to load.
2. KCardCache stores this information and opens the appropriate cache,
but doesn't yet load the SVG.
3. KCardCache launches an idle priority thread. (More on that in a bit.)
4. If KPat requests card pixmaps from the cache, KCardCache returns them.
5. If KPat requests card pixmaps that aren't in the cache, the SVG is
loaded (if it hasn't yet been) and the card is rendererd and returned.
6. Once the idle thread gets a chance to run it loads the SVG (if it
hasn't yet been loaded), checks to see which (if any) cards aren't
currently in the cache and then renders them all, returning them to
the main thread via signals and slots.

So lets say we just opened a new game of Spider but none of the
cards/sizes we need are cached. We're going to need some pixmaps as
soon as possible, so there's no way around it. We're forced to load
the SVG and render the face up cards in the main thread. Once the idle
thread gets a chance to run, it renders the front sides off all thos
facedown cards, so the pixmaps will be ready and waiting when it comes
time to flip them over.

On the other hand, if then shut KPat down and open up a new game of
Spider (with the same window size), all the pixmaps we need will
already be in the cache. So we don't load the SVG or render anything
in the main thread. When the idle thread runs, it'll see that it has
no rendering work to do, but it still loads the SVG, just so it'll be
ready if we need to resize the window.

This yielded significant performance improvements even on a single
core, non hyperthreaded system. On a modern multicore, it's especially
zippy. There is still plenty of room for further improvement of
course.

I realise that the above doesn't apply wholesale to KGoldRunner.
You'll need something simpler in some respects and more complicated in
others, but I hope the above was at least a little bit informative. If
there's one moral to take away, it's that loading an SVG can be as
expensive as rendering it, so delay or thread that whenever possible.

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

Hi Luciano,

No need to CC me (I am on the list) ... :-)

On Sat, 24 Oct 2009 9:41:35 pm Luciano Montanaro wrote:
> I have some issue with the way theming is implemented in KGoldrunner, we
> discussed it at KDE 4.0 time, but I think we are again at a bottleneck.
>
> I'm a bit sad that the only themes for KGoldRunner are from people on this
> list, and while that may mean there is little interest in the game, it may
> also mean it is too hard to make or modify themes.
>
Last time I looked there were about 10,000 downloads from Debian, but
lack of feedback from end-users is a hazard of OSS.  You cannot just ask
Accounts who has bought it, then go and visit them ... :-(  Even on forums
(such as KDE's) you mainly get "What happened to KSirtet, KSokoban,
etc?".  That's life.  People complain but rarely praise.

OTOH, the majority of people are not gifted artists, level composers or
programmers, but I am very happy with those we have here on this list.
I could not hope to work with a better bunch of guys.  I had hoped that
there would be more composers of levels, given that there has always
been a full-fledged game-editor, but only two or three have emerged in
about 7 years.  The situation may be the same with artists.  Anyway,
six themes is really great for one game ... :-)

So I do not think "build it and they will come" is going to work in this
case.  The only way to be sure is to conduct a survey, but how do you
find budding artists to read it and respond?  

> Furthermore, if Ian proceeds with the plan to implement XScavenger
> levels, we'll need a new kind of enemy, and a new treasure type
> (plus a few animations here and there).
>
My plans on that are in limbo ATM, but I was thinking of just putting a halo
around existing enemies and treasure.

> A solution could be improving caching, and not loading the svg file unless
> the window size changes and the tiles need to be regenerated. But this
> still means each window resize could involve along pause, before everything
> is rendered again.
>
I expect to commit a patch, maybe around Wednesday.  Then the SVG
overhead will be incurred only on first load and resize.  I don't know what
most people do, but I tend to stick to one size per game, browser or other
application, once I have found a size that suits me and my machine.

> The startup time reduction would resulting mainly from the fact that we do
> not load a gigantic svg file with many backgrounds, but only the background
> needed at the moment. And maybe we could use threads to load all the
> components in parallel. Even on single core machines, this should help.
>
I have thought about threads from time to time.  And thanks very much for
the heads-up on how it is done in KPat, Parker.  As a sometime real-time
programmer, I am not afraid of them, but I think the potential for bugs and
crashes tends to go as the square of the number of threads ... :-(

Some other ideas I have considered:

1. Look for a faster SVG renderer.  Inkscape (subjectively) seems faster.
2. Improve the performance of QSvgRenderer.
3. Reduce the detail in some of the SVG themes, thus reducing file sizes
    and rendering work.
4. Pre-render everything in large size and distribute it as PNG files, then
    use standard graphics transforms to resize.

Re 3, I do not wish to hurt anyone's feelings, especially not our artists,
but ...

The Egypt theme in KGoldrunner is a masterpiece IMO, however
it contains a great deal of detail which is invisible or almost invisible
after it has been rendered in a game.  For example, Matt Goldrunner
has a gleam in his eye (which is blue) and he is wearing a preppy
blazer with a stripe round the edge, but you can see none of this when
he is 20-30 pixels high.  Try putting the KMag magnifier onto him and
you will see.  Likewise, the temple background contains a frieze of
lovingly and beautifully drawn Egyptian heiroglyphics.  You must have
spent a long time drawing those, Eugene, but they are quite hard to see
when you are playing the game ... :-(

There, I've said it ... please do not be offended, Eugene.  Egypt is just an
example.  I think other themes in KDE Games could also be simplified.
This is nothing personal ... :-)

Re 4, after Akademy 2008 in Belgium, I went touring in Europe for a
few weeks and came back with about 1000 digital photos.  Then I
spent days with Digikam editing them.  I noticed that the picture
quality on-screen was about the same at a whole range of different
sizes.  The same is true in Palapeli.  So why not pre-render graphics
for KDE Games?

Re Palapeli and Kigo, two of my life-favorite pastimes, jigsaw puzzles
and Go, which I have had to give up due to young children, tidying
wives and lack of opponents, now appear in KDE Games.  I feel as if all
my Christmases have come at once!  Thanks very much, Stefan and
Sascha.  You are brilliant!

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

[Luciano Montanaro]

On domenica 25 ottobre 2009, Ian Wadham wrote:
> Hi Luciano,
>
> No need to CC me (I am on the list) ... :-)

Oh, sure, I guess I wanted to be sure to get your attention and that of
Eugene.

>
> On Sat, 24 Oct 2009 9:41:35 pm Luciano Montanaro wrote:
> > I have some issue with the way theming is implemented in KGoldrunner, we
> > discussed it at KDE 4.0 time, but I think we are again at a bottleneck.
> >
> > I'm a bit sad that the only themes for KGoldRunner are from people on
> > this list, and while that may mean there is little interest in the game,
> > it may also mean it is too hard to make or modify themes.
>
> Last time I looked there were about 10,000 downloads from Debian, but
> lack of feedback from end-users is a hazard of OSS.  You cannot just ask
> Accounts who has bought it, then go and visit them ... :-(  Even on forums
> (such as KDE's) you mainly get "What happened to KSirtet, KSokoban,
> etc?".  That's life.  People complain but rarely praise.
>
> OTOH, the majority of people are not gifted artists, level composers or
> programmers, but I am very happy with those we have here on this list.

Neither they are programmers, but we have a (bit) better luck finding that
kind of contribution, aren't we?

I guess my plan is to lure them with KGoldrunner theming, and then show them
they can have many occasions to exert their artistic vein with all our
production. Even as good our artists are, thee may soon be more work for them
than they can afford to make.

And really, customizing the game graphics may be a game in its own, which also
makes you learn new abilities. So even if in the end we do not get much
quality artwork, some kid could learn how to use inkscape. How's that bad?

> I could not hope to work with a better bunch of guys.  I had hoped that
> there would be more composers of levels, given that there has always
> been a full-fledged game-editor, but only two or three have emerged in
> about 7 years.  The situation may be the same with artists.  Anyway,
> six themes is really great for one game ... :-)
>

Uhm... maybe ome of the players actually design their levels, but they are shy
about their creation. Or maybe the editor is not good enough. ;)

> So I do not think "build it and they will come" is going to work in this
> case.  The only way to be sure is to conduct a survey, but how do you
> find budding artists to read it and respond?
>

I know it would simplify my own workflow, I did the graphics piecewise in
Nostagia and had to import/rename the actors graphics. I find too many objecs
on the page distract me. moreover, complex graphics is not a problem for Qt
SVG renderer, Inkscape also gets slower when too many objects are in the
document.

> > Furthermore, if Ian proceeds with the plan to implement XScavenger
> > levels, we'll need a new kind of enemy, and a new treasure type
> > (plus a few animations here and there).
>
> My plans on that are in limbo ATM, but I was thinking of just putting a
>  halo around existing enemies and treasure.
>

Well, with a separate file for each actor, you could do that. But it would be
also easy to copy an enemy and change it a bit - or a lot, as needed.

> > A solution could be improving caching, and not loading the svg file
> > unless the window size changes and the tiles need to be regenerated. But
> > this still means each window resize could involve along pause, before
> > everything is rendered again.
>
> I expect to commit a patch, maybe around Wednesday.  Then the SVG
> overhead will be incurred only on first load and resize.  I don't know what
> most people do, but I tend to stick to one size per game, browser or other
> application, once I have found a size that suits me and my machine.
>

I like to play KGoldrunner fullscreen, and that helps too. But not everybody
does that. And I sometime switch theme -- from Egypt to my own Nostalgia,
mainly.

> > The startup time reduction would resulting mainly from the fact that we
> > do not load a gigantic svg file with many backgrounds, but only the
> > background needed at the moment. And maybe we could use threads to load
> > all the components in parallel. Even on single core machines, this should
> > help.
>
> I have thought about threads from time to time.  And thanks very much for
> the heads-up on how it is done in KPat, Parker.  As a sometime real-time
> programmer, I am not afraid of them, but I think the potential for bugs and
> crashes tends to go as the square of the number of threads ... :-(
>

Uhm... sure, I've wanted to try out rendering the graphics with threads (using
ThreadPool) for a while. It's difficult to debug parallel programs, but as
long as the thread does a single thing (say render an SVG element) we should
be safe enough.

> Some other ideas I have considered:
>
> 1. Look for a faster SVG renderer.  Inkscape (subjectively) seems faster.
> 2. Improve the performance of QSvgRenderer.
> 3. Reduce the detail in some of the SVG themes, thus reducing file sizes
>     and rendering work.
> 4. Pre-render everything in large size and distribute it as PNG files, then
>     use standard graphics transforms to resize.
>

Yes, you could do any of those thing but...
*Even Inkscape has problems with some of our backgrounds
*We may want more than the current 2-3 backgrounds per theme

So the current approach does not scale, I think. It's OK for games with simple
graphics, or not many animations. But if we want, say, ten different
backgrounds instead of 3, loading up the svg file at startup with stuff that
will not be needed until much later is not the way to go. And The file size
will grow a lot, with ten backgrounds.

By the way, we could hide the background loading time when changing level:
we could fire a thread to load/render the new background when the scene is
completed, and it will be processed in the background while the bull's eye
animation is performed, for the most part. As soon as we receive a finished()
signal, we could resume the game.  

> Re 3, I do not wish to hurt anyone's feelings, especially not our artists,
> but ...
>
> The Egypt theme in KGoldrunner is a masterpiece IMO, however
> it contains a great deal of detail which is invisible or almost invisible
> after it has been rendered in a game.  For example, Matt Goldrunner
> has a gleam in his eye (which is blue) and he is wearing a preppy
> blazer with a stripe round the edge, but you can see none of this when
> he is 20-30 pixels high.  Try putting the KMag magnifier onto him and
> you will see.  Likewise, the temple background contains a frieze of
> lovingly and beautifully drawn Egyptian heiroglyphics.  You must have
> spent a long time drawing those, Eugene, but they are quite hard to see
> when you are playing the game ... :-(
>
> There, I've said it ... please do not be offended, Eugene.  Egypt is just
>  an example.  I think other themes in KDE Games could also be simplified.
>  This is nothing personal ... :-)
>

Well, while messing with my svgoptimize program, I've used the Oxygen mimetype
icons to test the results... There are a couple of icons that are in the
megabyte range, There is so much detail that will never be seen at any nomal
icon size. So Eugene is a saint, from my point of view. Still, yes, I agree
that some effort to keep rendering time under control would be beneficial.


Luciano


--
Luciano Montanaro //
                \X/ mikelima@...
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Arturo Silva]

Um........
Okay, don't mind the confusion as that was quite a long read, but are
you basically looking for more KGoldRunner themes, or just
brainstorming ideas on how to improve their performance, or both? ^^;
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Luciano Montanaro-3]

On Mon, Oct 26, 2009 at 1:24 AM, Arturo Silva <jasilva28@...> wrote:
> Um........
> Okay, don't mind the confusion as that was quite a long read, but are
> you basically looking for more KGoldRunner themes, or just
> brainstorming ideas on how to improve their performance, or both? ^^;

Both.
Actually, more than "more themes" I want better, compex themes -- I
want to be able to use different bricks for different levels, for
example, or different enemies.
With the current theme format, we run in performance problems soon --
we already have, actually. So, to improve things further, we need to
change some of the ways we are working, and I'd like to have input
from others on the list, and artists in particular.

I have other ideas, too -- the actor animation, for example, is
difficult to get right.
I'll look in a way to provide a program to help in tweaking the
animation frames.

It'll not be very user friendly, at first, just a way to show the
run/climb loops, at different speeds. It should notice if the svg file
changed, and reload the frames.

Or to do some kind of onion-skin work with the frames...

Later, some tool to animate an actor skeleton and to give a skin to
that would be nice, though it would be an harder work to do...
Who knows, that may be a useful subproject for Gluon.

If this gets polished, the user could also create their avatar to use in game.

And any 2-d platform game needs animations similar to those present in
KGoldrunner.
We want different mosters in different games, but the hero could be shared.


--
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Luciano Montanaro wrote:
> A solution could be improving caching, and not loading the svg file
> unless the window size changes and the tiles need to be regenerated.
> But this still means each window resize could involve along pause,
> before everything is rendered again.

What ever happened to using raster resize on the closest cached match
and re-rendering in the background? Wasn't that planned at one point? It
would look (temporarily) not as nice, but you'd be able to keep playing
instantly after a resize.

> The hero, enemy and gold-enemy have exactly the same frames, and
> could be swapped just by renaming them. We could have, for example,
> the Hero Mummy chased by Evil Adventurers!

I think this is a great idea :-). I mean, put yourself in the mummy's
position, how do you think /you/ would feel if a bunch of people broke
into your tomb and tried to steal your stuff?

(Okay, this would work better with a different rule set... you must
eliminate enemies and put all treasures back in initial places...
enemies start out carrying some treasure and try to collect all of it...
and try to kill you, of course. Maybe you also lose if they get all the
treasure and escape ;-).)


As far as making animation easier... um, ever look into the existing
Free animation tools? I see lists of reviews every now and then.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Joe: This is a big deal, because now some tiny minority has lobbied for
changes that end up hurting everyone else.
Bob: Yeah, I know. Par for the course. I hate the American government.
Joe: Actually, I was talking about X.org...

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

[Arturo Silva]

Hmmm... I have a couple of things to add about KGoldRunner in general,
but I'll need a little bit of time to collect my thoughts.  I honestly
didn't think KGoldRunner needed this much work -- from my previous
vantage point as a user it seemed relatively solid compared to the
other Kdegames.

Oh well, I guess if you do need help to make it even better (and
definitely to create an animation tool, that would just be supreme!),
then I will help as best I can.  :)

I'll talk later!


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