--===============1188329419== Content-Type: multipart/alternative; boundary="0-254178848-1228948999=:14415" --0-254178848-1228948999=:14415 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 ! You want feedback from maintainers, here it comes! ;) 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. 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. 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! Thanks for your understanding. Regards. -- Thomas GALLINARI --- En date de=C2=A0: Mer 10.12.08, Matthew Woehlke a =C3=A9crit=C2=A0: De: Matthew Woehlke Objet: Re: [Kde-games-devel] Kapman sprite system (also, connecting-tiles s= ystems) =C3=80: kde-games-devel@kde.org Date: Mercredi 10 D=C3=A9cembre 2008, 20h48 Mauricio Piacentini wrote: > Well, Matthew, it is difficult to argue with you. You asked for=20 > 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=20 advantage to that approach, and frankly, it drives me nuts when I go to=20 do artwork. Within that framework are questions like, does the hinting=20 system sound sane, does the .desktop layout sound sane, etc. And, to be fair, I guess no one has complained about the hinting (and=20 Eugene had a positive comment), so... As for the separate files, there were more complaints, and I'm=20 considering them. I'm not convinced (yet) about trying to put hashed=20 mazes in with everything else, but I will try to keep things so that=20 everything /else/ can be in one file, since I see no major disadvantage=20 there. So that feedback is also appreciated. As you may have noticed, the 'id everything' is a bit of a sore spot for=20 me, though :-). > But it seems like you already have a plan laid=20 > out, so maybe it is better to execute it, and if games pick it up then=20 > we can start embracing the shared classes, no problem! I am against=20 > restricting what people want to code by any sort of "group policy". >=20 > But in order to implement your goals, I think the Kapman maintainers=20 > 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=20 said in your other thread, I'd have to start a wholly new project.=20 Unfortunately, there would be a strong motivation for me to write=20 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=20 need to exercise, namely tile systems and sprite animation ...and because I can't think of anything else offhand I'd be motivated=20 to do. Obviously, because there is Kapman already I'd rather /not/=20 duplicate it. > For the games I am=20 > maintaining I prefer to keep the ID system for now, as it seems better=20 > to render individual tiles, and I do not want to make existing themes=20 > obsolete right now. A "compatibility mode" might be interesting, but anyway, I wouldn't=20 suggest anything more than to take that one game at a time. For Kapman=20 anyway I would probably do the work to convert all the existing themes=20 (of which there is, ah... one) myself. FWIW, for mahjongg tiles and card decks, what I remember of the themes=20 is that the work would be almost zero; those are mostly aligned already,=20 and inkscape can very easily and quickly clean up the small errors. > I do not think QSvgRenderer (or KSvgRenderer) allows this directly, does= =20 > it? The API allows to map the whole SVG to a Rect on the Painter, but I= =20 > think it does not allow choosing a rect in the SVG to render. By=20 > contrast, I was talking about the render method that takes an ID as a=20 > parameter, and allows optimized rendering of just this bit (as the SVG=20 > is already parsed and kept in the renderer object.) Like I said, I did it before in Kapman... It apparently used to work. I=20 don't know why it would no longer be working? I guess we'll find out. --=20 Matthew Please do not quote my e-mail address unobfuscated in message bodies. --=20 "Who wants to sing?" -- Orcs (Warcraft II) _______________________________________________ kde-games-devel mailing list kde-games-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-games-devel =0A=0A=0A --0-254178848-1228948999=:14415 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
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 !

You want feedback from maintainers, here it comes! ;)
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.

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.

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!

Thanks for your understanding.

Regards.

--
Thomas GALLINARI

--- En date de : Mer 10.12.08, Matthew Woeh= lke <mw_triad@users.sourceforge.net> a =C3=A9crit :
De: Matthew Woehlke <mw_triad@users.sourcefor= ge.net>
Objet: Re: [Kde-games-devel] Kapman sprite system (also, conn= ecting-tiles systems)
=C3=80: kde-games-devel@kde.org
Date: Mercredi = 10 D=C3=A9cembre 2008, 20h48

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

Feedback from Thomas/Pierre-Benoit would be nic=
e :-).

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

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

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

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

> But it seems like y=
ou 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 im=
plement 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 c=
ompleted
- It's a not-horribly-complicated game that touches the technol=
ogies I 
need to exercise, namely tile systems and sprite animation
<=
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/ 
d=
uplicate it.

> For the games I am 
> maintaining I prefer t=
o keep the ID system for now, as it seems better 
> to render individ=
ual tiles, and I do not want to make existing themes 
> obsolete righ=
t 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 a=
ll the existing themes 
(of which there is, ah... one) myself.

FW=
IW, 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, do=
es 
> it? The API allows to map the whole SVG to a Rect on the Painte=
r, but I 
> think it does not allow choosing a rect in the SVG to ren=
der. 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 addr=
ess unobfuscated in message bodies.
-- 
"Who wants to sing?" -- Orcs =
(Warcraft II)

_______________________________________________
kde=
-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.or=
g/mailman/listinfo/kde-games-devel
=
=0A=0A=0A=0A --0-254178848-1228948999=:14415-- --===============1188329419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kde-games-devel mailing list kde-games-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-games-devel --===============1188329419==--