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

[Matthew Woehlke]

Kleag wrote:
> Le Thursday 11 December 2008 00:34:04 Matthew Woehlke, vous avez �crit :
>> kleag at free.fr wrote:
>>> 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.
>> People complained when I wanted to put that information in the .desktop
>> ;-). And TBH I think it is more convenient in the svg, but I'd welcome
>> suggestions if someone thinks they have a better idea.
> Is there a possibility to add "user" elements, maybe RDF in a SVG file ? In 
> that case, you could put the semantic in the RDF and keep the id as what it 
> should be (IMO), an identifier

That would be better, as long as it's easy to edit. The only drawback I 
see is it isn't much effort to click on the obvious hint objects and see 
the values. Something embedded might make that harder. In all other 
respects, however, I agree with you.

Another option would be to use the sizes of hint objects to derive the 
needed information, but I worry about that being non-intuitive (mostly 
for the anim hints where you would have to key on absolute number of 
pixels) and/or unwieldy.

>>> 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
>> I take it you *do* use pixmap splitting, then? I guess I should try to
> Yes, sure, but I don't have to render the full graphics and then cut it in 
> sprites. I render the object element with all its frames and then split this 
> one.

Qt *should* be culling objects that don't intersect with the region bing 
rendered. If it isn't, I need to kick it :-). So you'd take culling 
overhead, but that's still rather different from "render the whole svg".

>> remember to give you a nudge if/when I have a usable frame-extracting
>> class, I wonder if you would be interested. (Actually... I think you
>> would be able to use it directly. I am already anticipating that it will
>> need a method that takes maybe an id for reference point but raw offsets
>> and width/height; you could certainly use that method with your existing
>> id's, no offset, and calculated width/height to extract frames as in
>> your sample.)
> I'll sure will consider any interesting solution, but really, I'm not for a 
> "one object and absolute coordinates". I prefer the "one id by object" 
> solution when possible. I'm not sure I understand well your statement above. 
> What do you mean by "raw offsets and width/height" ?

There really aren't any absolute coordinates, they're all relative to 
the reference object. As I understand, that's how your system already 
works. You just happen to be using the actual graphic /as/ the reference 
object. Which... is perfectly legal in the API I'm thinking about (it 
just means the offsets are 0,0). You'll have to calculate the size of 
each frame by hand (or have it stored somewhere), but I guess you do 
that already?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
|-\ /-\ \ | -+-   |-\  +  \ | -+- /-\
| | | | |\|  |    |-/ /-\ |\|  |  |
|-/ \-/ | \  |    |   | | | \ -+- \-/