[Kde-games-devel] Re: new KDE game: dominoes

[Jay Glascoe]

hi,

> How much space do the images take?

a lot. There's three flavors: small, medium, large
(24x48, 30x60, 36x72). Each consists of 120 images
(a lot) which is 2 reliefs, 2 face downs, 4 direction
arrows, and 112 domino faces (28 dominoes times 4
rotations each).

Uncompressed, each flavor takes up about 500k (I don't
know whether this is funny or tragic... ;-)

The good news is that I haven't made any effort at all
to reduce their size. Obviously, there's quite a few
things I could do. PNG compression is easy, but doesn't
really buy me much (2483 bytes to 2482 bytes... useless)
Color reduction is easy (mogrify -colors 16 foo.png), it
buys a much reduced size but at the price of loss of
image quality. Loss of image quality is okay, but I would
at least like to ensure that the resulting image looks
just as good at 8 bit resolution as 24. This means
selecting an adequate palette. And here we have entered
the realm of "I have no idea what I'm doing!"
(or, I do know how to use a palette: mogrify -map pal.gif
foo.png, but *I don't know how to make one*)

hmm. I don't know how to use the Gimp. I'd sort of like
to learn, but graphics really isn't my thing. I'd rather
spend my time learning, say, 3D programming (which I'm
half stuck into now, really really really cool stuff)
95% of the time, xv and the ImageMagick suite are more
than adequate for my image manipulation needs.

It also occurs to me that maybe I'm being stupid in
rotating the faces myself. In fact, I probably am being
stupid. Can the Qt pixmaps be trusted to rotate themselves
without information loss? Maybe. Hopefully. Let's see.
I originally chose to rotate the images myself (with shell
script calls to ImageMagick tools) due to lack of
familiarity with C++ and lack of familiarity with Qt.

This dominoes game is my "learn C++ project". Not a
school project, I'm long out of school (math MS), just
for personal beterment. My last endeavor was a "get back
in touch with my C coding" project: yet another solitaire
game written with Gtk+ (built my own canvas object,
learned a lot of X programming doing it 'cause Gtk+ is
about a millimeter's abstraction layer away from X).

Oh, this message is just too long. Here's some random
comments:

Qt is a lot easier to use than Gtk+. C++ is less painful
than C. All in all, Qt is the superior choice IMHO. But..
The (very limited and buggy) canvas I built with
Gtk+ for my solitaire game, for what it does (again,
not too much: drag and animated move) performs about
twice as well as QCanvas. I noticed a thread about
QCanvas a ways back here, my input is: how about a canvas
that does *less*. No 2D transformations, no collision
detection (leave it up to the programmer to tailor-make
this for performance), no sprite animations...

> Make sure they are in
> png format indexed 
> with optimal palette with as few colors as possible and
> highest compression 
> (i think all that can be done with gimp).
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-games-devel


__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2