Brutal Chess

Joe,

> 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 
original
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 
people.
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?

Cheers,
Guerkan

Guerkan,

> 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?

The problem here is the large amount of geometry with our current
model set. We are working on resolving this issue by creating a model
set with reduced polygon count. Our final goal is to have models that
are animated, as in Battle Chess (for the PC and other platforms). The
reason for redrawing so often is to allow for the interactivity that
we will need once animated pieces are added.

That said, all of our developer use the free OpenGL drivers without
problems. The textures load fine, though the framerate is a bit low.
The new model set should solve this problem.

> 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
> original
> 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...
>

A -data package will probably have to be added eventually. The
animated model set will be much larger in size than our current one
and all of the models will have textures accompanying them.

> Sounds good, I will test it...
>

Sourceforge's anonymous CVS is not updating at the moment. In the
meantime, I made a script to do a nightly tarball of the branch. You
can find it on our website.

> It was the green touch that I didn't like probably.
>

I have to admit, I'm not either, but I was overruled on that one. The
texture was originally black. Future releases will have different
board themes so everyone can be happy.

> 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).
>

Fair enough. If that's the way it's done, that's the way we will do it.

> 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
> people.
> 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?
>

Makes sense. We'll have to get a test machine to install it on.

As for OS X, since we are using SDL this is actually quite simple to
do. The only problem lies in getting all of the XCode build parameters
set properly (not sure what implications there are with making an
Intel build either).

-Joe