<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">As I said in a previous mail, we do not have a lot of time to spend on
Kapman for now, just be patient if we don't answer instantaneously
please !<br>
<br>
You want feedback from maintainers, here it comes! ;)<br>
IMO Mauricio and Eugene are two important artists of KDEGames, and they
both deal with IDs, as other artist seem to do. This is for me a
sufficient reason to keep the existing system that is used in Kapman.<br>
<br>
Another reason for that, is that a tile based maze will be a huge
change in the game, and moreover you seem to be ready to develop an
animation library (that is a very good point!). I don't think that it
is necessary to make the amount of work bigger than it needs to be.<br>
<br>
There is a last important thing to me: I (and Pierre-Benoit) agree to
let you working on Kapman since (I'm going to repeat myself) we don't
have time for now (and after all, the trunk is frozen). But we never
said that you could replace all our code by yours, (including code
formatting and so on)! Please be moderated and take our work and the
other developers advice in account before running to your computer and
refactor the whole Kapman, I could not work with you otherwise!<br>
<br>
Thanks for your understanding.<br>
<br>
Regards.<br>
<br>--<br>
Thomas GALLINARI<br><br>--- En date de : <b>Mer 10.12.08, Matthew Woehlke <i><mw_triad@users.sourceforge.net></i></b> a écrit :<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">De: Matthew Woehlke <mw_triad@users.sourceforge.net><br>Objet: Re: [Kde-games-devel] Kapman sprite system (also, connecting-tiles systems)<br>À: kde-games-devel@kde.org<br>Date: Mercredi 10 Décembre 2008, 20h48<br><br><pre>Mauricio Piacentini wrote:<br>> Well, Matthew, it is difficult to argue with you. You asked for <br>> feedback, we gave it.<br><br>Feedback from Thomas/Pierre-Benoit would be nice :-).<br><br>Yes, I've made up my mind w.r.t. not id'ing everything. I never saw an <br>advantage to that approach, and frankly, it drives me nuts when I go to <br>do artwork. Within that framework are questions like, does the hinting <br>system sound sane, does the .desktop layout sound sane,
etc.<br><br>And, to be fair, I guess no one has complained about the hinting (and <br>Eugene had a positive comment), so...<br><br>As for the separate files, there were more complaints, and I'm <br>considering them. I'm not convinced (yet) about trying to put hashed <br>mazes in with everything else, but I will try to keep things so that <br>everything /else/ can be in one file, since I see no major disadvantage <br>there. So that feedback is also appreciated.<br><br>As you may have noticed, the 'id everything' is a bit of a sore spot<br>for <br>me, though :-).<br><br>> But it seems like you already have a plan laid <br>> out, so maybe it is better to execute it, and if games pick it up then <br>> we can start embracing the shared classes, no problem! I am against <br>> restricting what people want to code by any sort of "group<br>policy".<br>> <br>> But in order to implement your goals, I think the Kapman maintainers <br>> have to
agree with it. If they do, no problem!<br><br>True, which is one reason I'm asking for feedback. And if not... as you <br>said in your other thread, I'd have to start a wholly new project. <br>Unfortunately, there would be a strong motivation for me to write <br>another Kapman, for several reasons:<br><br>- I've written a pac-man clone before<br>- I already have artwork completed<br>- It's a not-horribly-complicated game that touches the technologies I <br>need to exercise, namely tile systems and sprite animation<br><br>...and because I can't think of anything else offhand I'd be motivated <br>to do. Obviously, because there is Kapman already I'd rather /not/ <br>duplicate it.<br><br>> For the games I am <br>> maintaining I prefer to keep the ID system for now, as it seems better <br>> to render individual tiles, and I do not want to make existing themes <br>> obsolete right now.<br><br>A "compatibility mode" might be interesting, but
anyway, I<br>wouldn't <br>suggest anything more than to take that one game at a time. For Kapman <br>anyway I would probably do the work to convert all the existing themes <br>(of which there is, ah... one) myself.<br><br>FWIW, for mahjongg tiles and card decks, what I remember of the themes <br>is that the work would be almost zero; those are mostly aligned already, <br>and inkscape can very easily and quickly clean up the small errors.<br><br>> I do not think QSvgRenderer (or KSvgRenderer) allows this directly, does <br>> it? The API allows to map the whole SVG to a Rect on the Painter, but I <br>> think it does not allow choosing a rect in the SVG to render. By <br>> contrast, I was talking about the render method that takes an ID as a <br>> parameter, and allows optimized rendering of just this bit (as the SVG <br>> is already parsed and kept in the renderer object.)<br><br>Like I said, I did it before in Kapman... It apparently
used to work. I <br>don't know why it would no longer be working? I guess we'll find out.<br><br>-- <br>Matthew<br>Please do not quote my e-mail address unobfuscated in message bodies.<br>-- <br>"Who wants to sing?" -- Orcs (Warcraft II)<br><br>_______________________________________________<br>kde-games-devel mailing list<br>kde-games-devel@kde.org<br>https://mail.kde.org/mailman/listinfo/kde-games-devel<br></pre></blockquote></td></tr></table><br>