[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Kapman sprite system (also,
From:       kleag () free ! fr
Date:       2008-12-10 21:00:58
Message-ID: 1319351444.1582711228942858073.JavaMail.root () spooler10-g27 ! priv ! proxad ! net
[Download RAW message or body]

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@gmail.com>
À: piacentini@kde.org, "KDE games development" <kde-games-devel@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@kde.org 

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


["explosion.png" (image/png)]

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


[prev in list] [next in list] [prev in thread] [next in thread]