[Kde-games-devel] Kapman sprite system (also, connecting-tiles systems)

[Eugene Trounev]

I agree with Mauricio here. As an artist I love the ID system, as it makes my 
life so much easier. Also I really would like us to keep all the artwork in 1 
file per theme. Kpat is a good example of how bad this separation is (faces in 
one file, back in the other, background in third, game elements in forth, and 
fifth). However Matthew rises a valid point - KDEGames animation framework 
sucks :) And his idea of using Plasma like *hints* right inside svg files is 
very nice! .desktop configs are fine by the way.

On Wednesday 10 December 2008 07:03:16 Mauricio Piacentini wrote:
> Matthew Woehlke wrote:
> > Ok, so in fiddling with Kapman graphics, I ran into some problems with
> > the sprite system, mostly in the set of assumptions it makes (only one
> > enemy graphic, number of animation frames or lack thereof), and the
> > kdegames-wide item that has been the bane of my existence since 4.0,
> > requiring every bloody thing to have an id.
>
> ...
>
> > Let me say it again. I *hate* assigning id's to every blody thing. I
> > also hate having to group, and I really, *REALLY* hate having to make
> > invisible objects so that id'd things are the right size. As you'll no
> > doubt see from the attached svg's, I very much prefer defining elements
> > based on their position in the document. It's much easier (easier to
> > make, easier to edit, leads to neater svg's, no invisible objects, no
> > need to group)... and even allows tricks like frame re-use (check out
> > where the second four of eight frames for the blink animation are ;-) ).
> > Not to mention that for the enemies I have 22 id'd objects versus 80 I'd
> > need otherwise (and for the player, I'd otherwise need 36, and I have a
> > whole *2*).
> >
> > Anyway, one question is obviously if I can convince people to see the
> > light in this respect :-).
>
> Well, I do not agree with you, but I think we discussed this before in
> the mailing list a few months ago, didn't we? Assigning IDs works for
> all of the other games, and let authors free to not worry about pixel
> locations, which are troublesome in SVG art. It also brings imo other
> advantages: you COULD have code in the game to check for missed
> elements, for example, and you can let the theme author decide the scale
> and positioning of things in the game screen directly using SVG elements
> (like in KBlocks), without having to deal with keys in the .desktop files.
> All of these are not earth shattering features, but one is important
> imo: the ability of QSvgRenderer to render an element separately if you
> identify it by the ID. This alone is a huge benefit code wise: I am not
> sure how you are going to reproduce this in your whole SVG theme, but I
> think it will require rendering of the whole SVG and slicing the pixmaps
>   afterwards. It should not be problematic for Kapman, but in some cases
> (KMahjongg for example) it is bad to render the whole tileset and look
> for a specific position if you only want one element at a different
> size. Did you think about a solution to this yet?
>
> > The other big question is on the animation system itself, if it looks
> > sane, etc. Most of it is described in the README (which is written to
> > describe the whole theme but is incomplete at the moment). Basically,
> > it's magic-id to identify each sprite or block of sprites, with
> > additional magic id's to give the animation parameters and other hints.
> > Plus one magic id gives the size scale for everything. Obviously the
> > colors aren't important, but I've consistently used blue for block
> > identifiers, green for art hints (only one), and magenta for animation
> > hints. And red for the scale-indicator.
>
> ---
>
> > So... thoughts? Especially from Thomas and/or Pierre-Benoit? It's a
> > decent amount of work but will *really* open up new theming
> > possibilities.
> >
> > Implementation-wise, the first thing I plan on writing is obviously a
> > class to import multiple frames from a so-laid-out SVG; this will be
> > used both for the sprites and also the wall tiles. Then comes tile
> > logic... :-) I'm not sure if I'll want to tackle improving the animation
> > system or tying in a tile engine first; both are not changes to be made
> > while in freeze. (Maybe I should start a work branch in playground?)
>
> I think that you could try a branch to see how these ideas shape up. I
> still think using IDs open up more opportunities than it creates
> problems, and I think it is in line with what other SVG clients in the
> project are doing (plasmoids?)
> Thoughts from artists?
>
> Regards,
> Mauricio Piacentini
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20081210/9bf8e02f/attachment.htm