> Thanks for putting Brutal Chess in Debian, it has generated a fair
> amount of traffic for us.
You're welcome. Thanks for writing this game. Many people don't have
fast openGL non-free x drivers, would it be possible to just play it
wireframe like, or with much less redraws? Why draw the picture so
many times if nothing moves?
> I noticed that there was a bug in the Debian bugzilla, what was the
> cause of this? The comment I saw in the changelog was about adding
> alpha channels in the GIMP. The original images should have had an
> alpha channel (this was a requirement of the texture loader at the
> time). The next version won't have this problem (may have some endian
> issues, anyone have a big endian machine?).
The first bug was because of I removed the 1.9 MB pngs and replaced
them by autogenerated black/white.png without alpha. It works with
the non-free openGL drivers but not with them. Now I made the images
in GIMP and use those. This is a size thing. If i want to ship the
images, I need to split the package into a -data one and game one.
Since the package would use 11 x the size. -data packages are stored
just once for 11 archs...
> The development version, tentatively labeled 0.4 can be found in our
> Sourceforge CVS under the branch name nimble-knight. This branch is an
> almost complete rewrite, so not everything is working properly yet. We
> have been looking into FICS play, but are focusing most of our efforts
> on completing the remaining engine features. In our next release, we
> hope to allow play against gnuchess (or other chess engines that
> support the XBoard protocol. This is already working in CVS, but is
> far from complete.
Sounds good, I will test it...
> The reason for the large texture is to provide the most realistic
> marble possible. We have enlisted the help of an artist to do modeling
> and texturing, so it should look better by the next release. Various
> texture sizes will most likely be provided, to allow for operation on
> lower end graphics cards. An option to remove textures will probably
> also be present.
It was the green touch that I didn't like probably.
> This time of year is especially busy for us, due to finals and
> projects being due. Our aim is to have the next release ready by
> earl;y to mid summer. What sort of effort is needed to provide a
> Debian package?
Please do not provide a debian package, that's the best for Debian
and users. With Debian it's autobuilt for all arches, and another best
is the consistency of the packaging. One package for all, talk to me
if you think something needs be changed (or whoever is the current
debian package maintainer).
> We want to have more packages available for our next
> release (rpm, deb, ebuild, etc.) but most of our development team runs
> Gentoo. Is it even possible to do without a Debian system?
It's probably best to make rpm packages on a rpm based system (or
have them made by the users/distributors) as well as ebuild by Gentoo
I don't know, I don't use these systems. But what about a Mac OS X
version as well? Do you know Cocoa or GNUstep?