[criswell@geekcomix.com: Re: improper use of automake in Tux Typing]

[Jacek Konieczny]

The part about distribution is great. My answer is comming....

----- Forwarded message from Samuel Hart <criswell at geekcomix.com> -----

Delivered-To: jacek at localhost
Delivered-To: jajcus at bnet.pl
From: Samuel Hart <criswell at geekcomix.com>
To: Jacek Konieczny <jajcus at bnet.pl>
Subject: Re: improper use of automake in Tux Typing
Date: Tue, 7 Aug 2001 11:44:24 +0000
X-Mailer: KMail [version 1.2]
In-Reply-To: <20010807202138.A3300 at nic.gliwice.sdi.tpnet.pl>

On Tuesday 07 August 2001 06:21pm, Jacek Konieczny wrote:
> On Tue, Aug 07, 2001 at 09:56:22AM +0000, Samuel Hart wrote:
> > Actually, the problem stems from the fact that the project has been
> > developed primarily in the KDevelop 1.x series. KDevelop has a nasty
> > habit of commandering your project's build process (which is good if you
> > don't understand autoconf|make, which I didn't when I started the
> > project, but is bad if you start having good-sized projects).
>
> That's what I thought. But I was thinking "kdevelop could not bu such
> stupit so it don't allow to make proper Makefile.am". It seems I was
> wrong. :-(

Well, to be fair, KDevelop was originally started with other needs in mind. 
It was originally just a solution for KDE based applications.

It, of course, has since grown, and is used all over the place. But one of 
its /real/ problems is that the project templates it comes with are actually 
hard-coded into a header file in its source code:
http://lists.kde.org/?l=kdevelop&m=94795040008422&w=2

So anytime you want to use KDevelop for something not covered in the 
templates (such as an SDL app) you will face problems. (Unless you want to 
recompile KDevelop from source with a tweaked header file).

Like I said, after 2.0, they will have this fixed. I can't wait ;-)

> > Actually, the packagers that have an even harder time than RPM makers is
> > those making DEB packages (since Debian has a very strict file standard
> > that most other distros don't have).
>
> In our distro we have nearly such strict rules as Debian has. The mess
> in other RPM distributions is one of reasons why we are doing our own
> one.

That is a /very/ good thing. I actually gave up RPM based distros a while 
back because of this (and several other reasons ;-)

Are you guys planning on using the new rpm-get scheme? That was another big 
reason I switched to Debian (automatic package retrieval/updating). It seems 
like it'll be too hard for some of the *established* (stagnating? ;-) RPM 
based distros like RH, SuSE and Mandrake to start using it anytime soon... 
but some of the newer (younger? ;-) RPM based distros could easily do it.

Personally.... I like RPMs from a developers standpoint (because they are 
sooo much easier to make), and DEBs from an end-user standpoint (because I 
can be so lazy with respect to package management ;-)

> That's what i thought. But it would be great to have "very hard" mode,
> so adults can also enjoy the game :-). Graphics are cute :-)

One of the first things we want to impliment in the 1.x series is gameplay 
speed/difficulty sliders... So people can tweak the gameplay speed themselves.

> > If it's the title-screen, then the problem is actually a X server support
> > one. We use double-buffering to help speed up the full-surface blits.
> > Unfortunately, not all X servers support this ;-) If this is the problem
> > you are having, then you may want to try using the "-st"/"--static"
> > option with the game.
>
> Hmmmm.... The other solution I have in my mind whould be too much for
> this little game (why should there be dependency on OpenGL in it?).
> So maybe that's the way it should be :-).

Yes, we've thought about OpenGL as well. But you're right... way too many 
dependancies.

Now there has been some talk on the SDL dev mailing list to make an OpenGL 2D 
target as an option (meaning it would be transparent to the game developers, 
and optional to the end-users). If they do something like this, then Tux 
Typing will be ready to use it.

And actually, the speed during double-buffering can be greatly increased if 
you are using a XFree86 4.0 or later, and your hardware is appropriately 
supported (supports DRI, etc.)

But it's funny... My desktop is a 300MHz AMD K6 with a very cheesy ATI Rage 
Pro card, and yet Tux Typing performs /way/ better on it than on my 500Mhz 
laptop with a high-performance (for DVD playback) video chipset!

-- 
Sam "Criswell" Hart <criswell at geekcomix.com> AIM, Yahoo!: <criswell4069>
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >


----- End forwarded message -----