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

[Matthew Woehlke]

Mauricio Piacentini wrote:
> Well, Matthew, it is difficult to argue with you. You asked for 
> feedback, we gave it.

Feedback from Thomas/Pierre-Benoit would be nice :-).

Yes, I've made up my mind w.r.t. not id'ing everything. I never saw an 
advantage to that approach, and frankly, it drives me nuts when I go to 
do artwork. Within that framework are questions like, does the hinting 
system sound sane, does the .desktop layout sound sane, etc.

And, to be fair, I guess no one has complained about the hinting (and 
Eugene had a positive comment), so...

As for the separate files, there were more complaints, and I'm 
considering them. I'm not convinced (yet) about trying to put hashed 
mazes in with everything else, but I will try to keep things so that 
everything /else/ can be in one file, since I see no major disadvantage 
there. So that feedback is also appreciated.

As you may have noticed, the 'id everything' is a bit of a sore spot for 
me, though :-).

> But it seems like you already have a plan laid 
> out, so maybe it is better to execute it, and if games pick it up then 
> we can start embracing the shared classes, no problem! I am against 
> restricting what people want to code by any sort of "group policy".
> 
> But in order to implement your goals, I think the Kapman maintainers 
> have to agree with it. If they do, no problem!

True, which is one reason I'm asking for feedback. And if not... as you 
said in your other thread, I'd have to start a wholly new project. 
Unfortunately, there would be a strong motivation for me to write 
another Kapman, for several reasons:

- I've written a pac-man clone before
- I already have artwork completed
- It's a not-horribly-complicated game that touches the technologies I 
need to exercise, namely tile systems and sprite animation

...and because I can't think of anything else offhand I'd be motivated 
to do. Obviously, because there is Kapman already I'd rather /not/ 
duplicate it.

> For the games I am 
> maintaining I prefer to keep the ID system for now, as it seems better 
> to render individual tiles, and I do not want to make existing themes 
> obsolete right now.

A "compatibility mode" might be interesting, but anyway, I wouldn't 
suggest anything more than to take that one game at a time. For Kapman 
anyway I would probably do the work to convert all the existing themes 
(of which there is, ah... one) myself.

FWIW, for mahjongg tiles and card decks, what I remember of the themes 
is that the work would be almost zero; those are mostly aligned already, 
and inkscape can very easily and quickly clean up the small errors.

> I do not think QSvgRenderer (or KSvgRenderer) allows this directly, does 
> it? The API allows to map the whole SVG to a Rect on the Painter, but I 
> think it does not allow choosing a rect in the SVG to render. By 
> contrast, I was talking about the render method that takes an ID as a 
> parameter, and allows optimized rendering of just this bit (as the SVG 
> is already parsed and kept in the renderer object.)

Like I said, I did it before in Kapman... It apparently used to work. I 
don't know why it would no longer be working? I guess we'll find out.

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