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

[Matthew Woehlke]

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?

Yes, and you failed to convince me then (or now).

> 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.

...and yet, icon artists seem to manage just fine. Honestly, IMO either 
that level of precision isn't an issue either way, or else you need to 
be using a grid, in which case you're "troubling with pixel locations" 
either way.

And, for single-frame sprites, you can still assign the id to the sprite 
itself with zero offset.

It's not *quite* as bad for sprites as it is for walls (which need to be 
pixel-perfect anyway, at least relative to each other), but something 
like the player-dead sprite would need invisible bounding objects for 
every frame with id-everything. (Have I mentioned how much I despise 
needing to create all those invisible bounding objects?)

> It also brings imo other advantages: you COULD have code in the game
> to check for missed elements, for example,

You *will* have code to check for missed elements with my system. If the 
orientation id doesn't exist, you can't extract the sprite frames. At 
worst you'll have missing or fudged frames. I disagree that trying to 
enforce non-broken themes in code is useful; if I want to make a broken 
theme, I can do it easily in the current system. It won't hold your hand 
quite as firmly, but do we /really/ need that?

(Incidentally, there is an /intentionally/ empty frame in the 
sprites.svgz I posted... can you spot it?)

> 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.

Yes, you convinced me of not using the .desktop for things :-). You may 
also notice I didn't include a .desktop, because it doesn't contain this 
information (just a reference to the correct file name).

> 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.

Rendering a specific portion of an svg is not rocket science either, 
therefore I fail to see that this is as advantageous as you claim.

> 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.

Nope, not needed. You can render parts of an svg.

> I think that you could try a branch to see how these ideas shape up.

Obviously, since trunk is frozen ATM.

> 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?

This artist thinks 'everything has an id' is a total PITA.

 From a /pure programming perspective/ I can understand the preference 
for requiring everything to have an id. From the perspective of actually 
making a theme, it's a PITA. (And, since I'm going to build a reusable 
class for rendering this sort of thing, the 'difficult to code' argument 
isn't worth much.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Who wants to sing?" -- Orcs (Warcraft II)