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

[kleag at free.fr]

Hello,

The solution in KsirK is intermediary: Everything is in one svg and there is one element with id by object but then all the frames of the object are in the same element. The information on how to cut the object in individual frames is found in the world.desktop file. I don't like to have parseable ids. For me, ids are atomic pieces of information. The attached image shows the element with id "exploding" in the svg and its description in the .desktop is below:
[exploding]
frames=4
height=32
id=exploding
versions=2
width=32


The AnimSprite class is a QGraphicsPixmapItem and itr also contains a list of pixmaps for the frames. Then a slot connected to a timer (local to the sprite ; should it be global ?) calls setPixmaps regularly.

It works OK with 100 to 200 sprites.

The problem in the ksirk case, is the moving animation solution: an old ang ugly solution that I plan to refactor for 4.3 (using the Qt animation framework as a basis). If work is done on that before I start, I sure will try it.

Bye.

Gaël
----- Mail Original -----
De: "Eugene Trounev" <eugene.trounev at gmail.com>
À: piacentini at kde.org, "KDE games development" <kde-games-devel at kde.org>
Envoyé: Mercredi 10 Décembre 2008 17:37:56 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [Kde-games-devel] Kapman sprite system (also, connecting-tiles systems)




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 
_______________________________________________
kde-games-devel mailing list
kde-games-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: explosion.png
Type: image/png
Size: 10826 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20081210/b0e8fb73/attachment.png