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

[Mauricio Piacentini]

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