tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src Driver.h,1.14,1.15 joystick.h,1.3,1.4 PlayerDriver.cxx,1.12,1.13 sdldrv.cxx,1.16,1.17 sdldrv.h,1.6,1.7

[Ingo R. <gr...@gm...>]

Ryan Flegel <rf...@gm...> writes:

> Is this necessary? If you're moving something away from PLIB their
> should be good reasons, like there was for the GUI. I can't really
> see why there would be any problems with PLIB for input.

Well, if SDL is already used for all input, there is little reason to
keep the PLIB stuff in place for the joystick. Doing it all with SDL
would just unify the events handling a bit. Sure its not necesarry,
but we don't lose anything that way either. Anyway, input handling
needs to get a good cleanup anyway, handling of digital devices is
terrible at the moment and input-recording, multipler and
configurability are also on the TODO.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

[TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src Driver.h,1.14,1.15 joystick.h,1.3,1.4 PlayerDriver.cxx,1.12,1.13 sdldrv.cxx,1.16,1.17 sdldrv.h,1.6,1.7

[Ryan F. <rf...@gm...>]

On Sat, 07 Aug 2004 03:38:41 +0000,
tux...@li...
<tux...@li...> wrote:
> Update of /cvsroot/tuxkart/tuxkart/src
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7377/src
> 
> Modified Files:
>         Driver.h joystick.h PlayerDriver.cxx sdldrv.cxx sdldrv.h
> Log Message:
> - Changed PLIB joystick stuff to SDL joystick stuff...Steve won't be happy

Is this necessary? If you're moving something away from PLIB their
should be good reasons, like there was for the GUI. I can't really see
why there would be any problems with PLIB for input.

-- 
Ryan

[TuxKart-devel] Split screen multiplayer

[James G. <jam...@bt...>]

I'd like to try and implement split screen multiplayer, if that's OK
with other people?

The code to actually split the screen up is already there, so it's
basically just a matter of sorting out some controls (I hope). In the
future we need a config screen to setup controls, plus they'll need to
be saved to a file on game exit so it remembers your choices, but for
now they'll just be compiled in.

	James

[TuxKart-devel] comments on the New tracks

[Pascal G. <pa...@gu...>]

> i've found some but not all of them in our directory
> (http://www.mathematik.uni-bielefeld.de/~ingo/).

first, i meant "your", not "our".

--

about the tracks, just as you mentionned before (Grumbel), i experience lags
at tracks start. It wasn't having that before, i was having the lag after the
track had started.

i've the start-lag in only 2 tracks.
i can't start until i reach the 34th second in "Little Vulcano";
until i reach the 19th second in "On the Beach".

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

[TuxKart-devel] New tracks

[Pascal G. <pa...@gu...>]

Hi there Grumbel,
  please add the missing textures to the CVS...

i've found some but not all of them in our directory
(http://www.mathematik.uni-bielefeld.de/~ingo/).

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

Re: [TuxKart-devel] Compilation error on cvs

[Ryan F. <rf...@gm...>]

On Fri, 6 Aug 2004 19:32:13 +0100, Ricardo Cruz <ri...@ae...> wrote:
> 
> Hello there,
> 
>  I am getting this error on CVS for a while now:
> 
> if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"tuxkart\"
> -DVERSION=\"0.4.0\" -DHAVE_LIBSDL=1 -DHAVE_LIBSDL_IMAGE=1 -DHAVE_LIBSDL_TTF=1
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBGL=1 -DSTDC_HEADERS=1
> -DHAVE_GL_GL_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1
> -DTUXKART_DATADIR=\"/usr/local/share/games/tuxkart\"  -I. -I.     -g -O2
> -I/usr/include/SDL -D_REENTRANT -O6 -Wall -Wall -W -Werror -DDEBUG -g -MT
> start_tuxkart.o -MD -MP -MF ".deps/start_tuxkart.Tpo" \
>   -c -o start_tuxkart.o `test -f 'start_tuxkart.cxx' || echo
> './'`start_tuxkart.cxx; \
> then mv -f ".deps/start_tuxkart.Tpo" ".deps/start_tuxkart.Po"; \
> else rm -f ".deps/start_tuxkart.Tpo"; exit 1; \
> fi
> In file included from start_tuxkart.cxx:20:
> /usr/include/plib/pw.h:18: error: `NULL' was not declared in this scope
> /usr/include/plib/pw.h:18: error: `NULL' was not declared in this scope
> /usr/include/plib/pw.h:19: error: `NULL' was not declared in this scope
> /usr/include/plib/pw.h:19: error: `NULL' was not declared in this scope
> /usr/include/plib/pw.h:20: error: `NULL' was not declared in this scope
> make[1]: ** [start_tuxkart.o] Erro 1
> make[1]: Leaving directory `/home/prog/tuxkart/tuxkart/src'
> make: ** [all-recursive] Erro 1
> 
>  Any ideas?

Add one of the standard libraries to pw.h:

#include <cstddef>

-- 
Ryan

[TuxKart-devel] Compilation error on cvs

[Ricardo C. <ri...@ae...>]

Hello there,

 I am getting this error on CVS for a while now:

if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"tuxkart\" 
-DVERSION=\"0.4.0\" -DHAVE_LIBSDL=1 -DHAVE_LIBSDL_IMAGE=1 -DHAVE_LIBSDL_TTF=1 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBGL=1 -DSTDC_HEADERS=1 
-DHAVE_GL_GL_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1 
-DTUXKART_DATADIR=\"/usr/local/share/games/tuxkart\"  -I. -I.     -g -O2 
-I/usr/include/SDL -D_REENTRANT -O6 -Wall -Wall -W -Werror -DDEBUG -g -MT 
start_tuxkart.o -MD -MP -MF ".deps/start_tuxkart.Tpo" \
  -c -o start_tuxkart.o `test -f 'start_tuxkart.cxx' || echo 
'./'`start_tuxkart.cxx; \
then mv -f ".deps/start_tuxkart.Tpo" ".deps/start_tuxkart.Po"; \
else rm -f ".deps/start_tuxkart.Tpo"; exit 1; \
fi
In file included from start_tuxkart.cxx:20:
/usr/include/plib/pw.h:18: error: `NULL' was not declared in this scope
/usr/include/plib/pw.h:18: error: `NULL' was not declared in this scope
/usr/include/plib/pw.h:19: error: `NULL' was not declared in this scope
/usr/include/plib/pw.h:19: error: `NULL' was not declared in this scope
/usr/include/plib/pw.h:20: error: `NULL' was not declared in this scope
make[1]: ** [start_tuxkart.o] Erro 1
make[1]: Leaving directory `/home/prog/tuxkart/tuxkart/src'
make: ** [all-recursive] Erro 1


 Any ideas?

 I'm using Mandrake 10.0, having 3.3.2 version of g++.

Thanks,

 Ricardo

-- 
Hewett's Observation:
	The rudeness of a bureaucrat is inversely proportional to his or
	her position in the governmental hierarchy and to the number of
	peers similarly engaged.

Re: [TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src widget_glext.h,1.1,1.2 widget_image.cxx,1.1,1.2 widget_mathdef.h,1.1,1.2

[James G. <jam...@bt...>]

On Fri, 2004-08-06 at 13:20, Robert Kooima wrote:
> On Fri, 06 Aug 2004 14:03:10 +0200, Ingo Ruhnke <gr...@gm...> wrote:
> 
> > > - * Copyright (C) 2003 Robert Kooima
> 
> Please don't remove my name from my code.

OK, sorry, I've put it back now.

	James

Re: [TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src widget_glext.h,1.1,1.2 widget_image.cxx,1.1,1.2 widget_mathdef.h,1.1,1.2

[Charles G. <ch...@ve...>]

Ingo Ruhnke wrote:

>>- * Copyright (C) 2003 Robert Kooima
>>    
>>
>Removing the copyright notice is actually a violation of the GPL.
>

Actually, no it isn't.  As long as you redistribute code under the GPL, 
you can take somebody else's GPL code, simply put your name in the 
copyright notice, and you are not violating the GPL.

You're thinking about the BSD or X11 license.

Still, on principle, I don't agree with removing authors' names from code.

- Charlie

Re: [TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src widget_glext.h,1.1,1.2 widget_image.cxx,1.1,1.2 widget_mathdef.h,1.1,1.2

[Robert K. <rob...@gm...>]

On Fri, 06 Aug 2004 14:03:10 +0200, Ingo Ruhnke <gr...@gm...> wrote:

> > - * Copyright (C) 2003 Robert Kooima

Please don't remove my name from my code.

-- 
Robert Kooima

[TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src widget_glext.h,1.1,1.2 widget_image.cxx,1.1,1.2 widget_mathdef.h,1.1,1.2

[Ingo R. <gr...@gm...>]

tux...@li... writes:

> Changed the headers to say TuxKart rather than Neverball
> +//  $Id$
> +//
> +//  TuxKart - a fun racing game with go-kart
> +//  Copyright (C) 2004 Steve Baker <sjb...@ai...>
>
> -/*   
> - * Copyright (C) 2003 Robert Kooima

Very bad idea, the neverball GUI code is still written, by Robert, not
by Steve so the Copyright (c) should point to Robert. Removing the
copyright notice is actually a violation of the GPL. If you do modify
some file written by somebody else, just add yourself to the list of
names in the copyright notice, but don't change the other people
listed there.

Reformating the copyright notice itself to fit with the rest of the
files itself should be ok however, you just shouldn't change the
names.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

[TuxKart-devel] GUI fonts

[James G. <jam...@bt...>]

Sorry, I accidently pressed some keyboard shortcut that made the message
send to early.

As I was saying, dolphin told me the reason ttf fonts were just coming
out as white blocks was because of a lack of:

glEnable(GL_TEXTURE_2D);

and he was right. However, I don't know quite where this should be put -
I tested it just by throwing it in the middle of the main loop, but I
assume that's not right. Could some OpenGL dude possibly put it in the
right place?

Thanks,

James

[TuxKart-devel] GUI font

[James G. <jam...@bt...>]

dolphin told me the reason ttf fonts were just coming out as white
blocks was because of a lack of 

Re: [TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src Driver.h,1.10,1.11

[Pascal G. <pa...@gu...>]

> How drivable should it be now? For me driving is now quite close to
> the original code, but FAR to fast. Is it just that the values need
> more tweaking or are parts of the physics code dependant on the CPU
> speed?

it wasn't modified by Jacob, it was modified by me.
it's just as playable as in "at least i have more patience in order to test
tracks".

it _HAS_ to be corrected.

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

[TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src Driver.h,1.10,1.11

[Ingo R. <gr...@gm...>]

tux...@li... writes:

> Update of /cvsroot/tuxkart/tuxkart/src
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20108/src
>
> Modified Files:
> 	Driver.h 
> Log Message:
> - Just made it drivable again...

How drivable should it be now? For me driving is now quite close to
the original code, but FAR to fast. Is it just that the values need
more tweaking or are parts of the physics code dependant on the CPU
speed?

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [TuxKart-devel] adding/replacing current karts

[Jeremiah H. <jho...@us...>]

correction www.geocities.com/ensholtus/deathkart.tgz

>On Wednesday 04 August 2004 17:57, Ingo Ruhnke wrote:
> Jeremiah Holt <jho...@us...> writes:
> > is it possible to replace the karts with alternate ones? I've
> > tried simplely overwriting te curent models but I get
> > the error below after clicking te Start button
> > FATAL: ac_to_gl: Unrecognised token 'crease 45.000000
>
> Overwriting works perfectly fine for me, looks like have run into a
> limitation of either the export script or plibs ac3d loader. Do you
> have that model somewhere available online?

Re: [TuxKart-devel] adding/replacing current karts

[Jeremiah H. <jho...@us...>]

I'm using ac3d to create this item its uploaded to www.geocities.com/
ensholtus/deathkart.ac 
>On Wednesday 04 August 2004 17:57, Ingo Ruhnke wrote:
> Jeremiah Holt <jho...@us...> writes:
> > is it possible to replace the karts with alternate ones? I've
> > tried simplely overwriting te curent models but I get
> > the error below after clicking te Start button
> > FATAL: ac_to_gl: Unrecognised token 'crease 45.000000
>
> Overwriting works perfectly fine for me, looks like have run into a
> limitation of either the export script or plibs ac3d loader. Do you
> have that model somewhere available online?

Re: [TuxKart-devel] adding/replacing current karts

[Ingo R. <gr...@gm...>]

Jeremiah Holt <jho...@us...> writes:

> is it possible to replace the karts with alternate ones? I've 
> tried simplely overwriting te curent models but I get 
> the error below after clicking te Start button 
> FATAL: ac_to_gl: Unrecognised token 'crease 45.000000

Overwriting works perfectly fine for me, looks like have run into a
limitation of either the export script or plibs ac3d loader. Do you
have that model somewhere available online?

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

[TuxKart-devel] adding/replacing current karts

[Jeremiah H. <jho...@us...>]

is it possible to replace the karts with alternate ones? I've 
tried simplely overwriting te curent models but I get 
the error below after clicking te Start button 
FATAL: ac_to_gl: Unrecognised token 'crease 45.000000

Re: [TuxKart-devel] Physics

[James G. <jam...@bt...>]

On Tue, 2004-08-03 at 22:09, Pascal Giard wrote:
> Hi there guys,
>   in the current CVS state, i was just wondering if tuxkart was suppose to be
> playable (drivable) ?
> 
> With both Keyboard and analog joystick (Logitech Wingman RumblePad) it doesn't
> turn enough and it slides too much... not enough grip ?
> 
> In fact, it slides on the sides while i've almost no speed...
> I'd be glad to help and fix the physic code, but so far, i don't get it.
> 
> With a bit of explanation, i might be able to catch up.
> (I've a good knowledge of dynamic vector mecanics, but never used that
> knowledge in a computer environment/ in coding)
> 
> Is the code entirely based on http://home.planet.nl/~monstrous/tutcar.html ?

Straver is doing the physics, and yes as you say it's unplayable at the
moment.

Apparently you can adjust the constants in the physics code using the
number keys and then + and -, I don't know how much it just needs
tweaking and how much the actual code needs changing.

	James

[TuxKart-devel] Physics

[Pascal G. <pa...@gu...>]

Hi there guys,
  in the current CVS state, i was just wondering if tuxkart was suppose to be
playable (drivable) ?

With both Keyboard and analog joystick (Logitech Wingman RumblePad) it doesn't
turn enough and it slides too much... not enough grip ?

In fact, it slides on the sides while i've almost no speed...
I'd be glad to help and fix the physic code, but so far, i don't get it.

With a bit of explanation, i might be able to catch up.
(I've a good knowledge of dynamic vector mecanics, but never used that
knowledge in a computer environment/ in coding)

Is the code entirely based on http://home.planet.nl/~monstrous/tutcar.html ?

-Pascal
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

Re: [TuxKart-devel] Some notes

[Ricardo C. <ri...@ae...>]

Em Ter=E7a, 3 de Agosto de 2004 05:27, o Pascal Giard escreveu:
> >  James enumerated 5 reasons for the use of SDL. My point was just
> > that it is stupid to say that it should be used because everyone has
> > it.
>
> To some's opinion, SDL just answer various needs in order to improve
> tuxkart. To Steve's point of view, it's possible to improve tuxkart witho=
ut
> SDL since some of those "needs" aren't that important.
>
> I can not comment on many issues, but i think it would be nice to be able
> to play fullscreen in 320x240 [on slow PCs].
>
 Yes, it is nice and I maybe necessary to have full screen support for=20
different resolutions.
 But not to make it running in slow PCs, because I don't think you can run=
=20
TuxKart with software rendering and a crap cpu (even in a fast one it would=
=20
be damn slow).
 The need for it is for cheap guys like myself that buy the bottom line of=
=20
accelerated video cards and use a desktop resolution of 1280x1024.

> >  Anyway, you say dependencies is not a =ABbad thing=BB. You do have to
> > agree, that even if it is in a very small degree, it is not really
> > that good. Dependencies mean bigger binaries, might have portability
> > problems and the ask for more maintenance.
>
> Bigger binairies, as long as the binairies are staticly linked.
> I agree that staticly linked binairies are usually bigger because the libs
> they depend on have more features than needed.
>
> IMHO, the issue here is that Steve believes we can achieve everything we
> need with Plib.
>
> Still, i think SDL isn't a portability issue as libsdl is available in
> debian for 11 architectures=B9.
>
> As to either it needs more maintenance or not, it surely needs more.
> But some suggested (previously on this list) that someone else than Steve
> would maintain the non-Plib stuff. I might have misunderstood the msg
> behind: "If you can maintain the PLIB side of those IFDEFS then everybody
> will be happy.".
>
 First of all, I said it was in a small degree. And no, portability doesn't=
=20
only dependend from the library, but from the use one makes of it.

Cheers,
 Ricardo

=2D-=20
modem, adj.:
	Up-to-date, new-fangled, as in "Thoroughly Modem Millie."  An
	unfortunate byproduct of kerning.

	[That's sic!]

Re: [TuxKart-devel] Some notes

[Pascal G. <pa...@gu...>]

>  James enumerated 5 reasons for the use of SDL. My point was just 
> that it is stupid to say that it should be used because everyone has 
> it.

To some's opinion, SDL just answer various needs in order to improve tuxkart.
To Steve's point of view, it's possible to improve tuxkart without SDL since
some of those "needs" aren't that important.

I can not comment on many issues, but i think it would be nice to be able to
play fullscreen in 320x240 [on slow PCs].

>  Anyway, you say dependencies is not a «bad thing». You do have to 
> agree, that even if it is in a very small degree, it is not really 
> that good. Dependencies mean bigger binaries, might have portability 
> problems and the ask for more maintenance.

Bigger binairies, as long as the binairies are staticly linked.
I agree that staticly linked binairies are usually bigger because the libs
they depend on have more features than needed.

IMHO, the issue here is that Steve believes we can achieve everything we need
with Plib.

Still, i think SDL isn't a portability issue as libsdl is available in debian
for 11 architectures¹.

As to either it needs more maintenance or not, it surely needs more.
But some suggested (previously on this list) that someone else than Steve
would maintain the non-Plib stuff. I might have misunderstood the msg behind:
"If you can maintain the PLIB side of those IFDEFS then everybody will be happy.".

-Pascal
¹ http://packages.debian.org/stable/libs/libsdl1.2debian
or more generally:
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libsdl&searchon=names&subword=1&version=all&release=all
--
Projet MoviXMaker (http://sv.gnu.org/projects/movixmaker)
Projet [e]MoviX[2] (http://movix.sf.net) 
Debian Project (http://www.debian.org)
TuxKart (Wiki (GOTM): http://netpanzer.berlios.de/tuxkart/index.php)

Re: [TuxKart-devel] tuxkart GUI

[James G. <jam...@bt...>]

On Mon, 2004-08-02 at 20:36, Matze Braun wrote:
> This mail is mainly for James...:
> 
> As I have nothing to do in tuxkart at the moment, I'd like to work on the 
> GUI. 

Actually, looks like it might be 48 hours until I commit some new GUI
stuff.

It depends on how much free time you have in the next couple of days,
but if it's a lot maybe you could do some AI stuff, or try to fix the
"fall-through the track" bug, or sort out the camera in split-screen
mode (it often points too far up)? Or maybe you have some real-life
stuff to attend to, too...

	James

Re: [TuxKart-devel] Some notes

[Ricardo C. <ri...@ae...>]

Em Segunda, 2 de Agosto de 2004 12:54, o Ingo Ruhnke escreveu:
> Ricardo Cruz <ri...@ae...> writes:
> > Em Segunda, 2 de Agosto de 2004 03:00, o James Gregory escreveu:
> >> As for the issues with not using SDL:
> >>
> >> 1. No fullscreen mode
> >
> >  --fullscreen is working fine here. Does it have problems in some
> > systems?
> >
> >  About the no possibility of using a size different than screen size,
> > Steve said there shouldn't be any performance decrease. And I haven't
> > noticed any either.
>
> The latest CVS already uses SDL, so fullscreen is working fine there.
> Without use of SDL all plib-pw could do was open a borderless window
> at the size of your desktop, which naturally would result in a
> resolution a lot larger then needed, not something you want for lower
> end hardware.
>
 It really is weird that Plib doesn't support other resolutions than the=20
desktop.
 Steve, can't this be fixed?

> >> 2. GUI-wise being limited to using what plib provides
> >
> >  I believe it is as rich as ClanLib GUI module and other GUI libraries.
>
> ClanLibs GUI is much like plibs GUI something that I would call a
> 'business-gui', ie. provides all the widgets that you get from a
> normal gui toolkit, but little to no stuff that you would need for
> games (animated jumping letters, joystick controll, etc.). Its ok if
> you do a Transport Tycoon/SimCity type of game and just need a bit
> theming, but do any good for arcade games.
>
 I know what you mean and I have always agreed to making a home-made menu=20
oriented interface, rather than a scroll bar, push buttons and so on.
 My point was the one above, that I believe Plib can support simple things =
as=20
image and true-type font handling.

> >  But even if we decide to do a custom GUI code, can't we use its
> > image and text capabilities?
>
> Neverball-GUI already provides all we need and doesn't depend on
> anything but SDL_image and SDL_ttf, which should be pretty much
> widespread since a whole lot of games use them.
>
 I guess it would be harmless to use SDL and bros. and, in the future, port=
 it=20
to use Plib stuff.

> >  About physfs, isn't that a physics library? If yes, wasn't it
> > decided that it would be better to make a home made physics.
>
> ODE was the physic library, physfs is a file loading library that does
> things like transparently 'mounting' zip files as directories and
> such.
>
 You do have to agree that Physfs sound like Physics. ;)

> >  Well, those people already knew TuxKart used Plib and there was no
> > opposition regarding that. Besides, Plib is pretty small and I guess
> > they already had time to learn, at least, the basics.
>
> This whole thing isn't about plib vs. SDL, we for sure will still use
> plib for all the scene-graph stuff and model loading stuff, its just
> that having support for TTF loading, pngs, jpegs and a real fullscreen
> mode would be extremly helpfull.
>
 My point was that programmers should make an effort to use Plib, but if it=
=20
just takes too much time and doesn't do something right.
 But in the future, I guess it would be nice to fix Plib and make use of it.

> >> 5. Everyone who ever compiles games already has SDL, SDL_image etc in
> >> any case
> >
> >  Why not linking to Allegro, ClanLib - you name it - as well.
> >  "Everyone who ever compiles games already" have those. ;D
>
> Compared to SDL, Allegro and ClanLib are far less widespread and at
> least ClanLib also has the tendency to break the API every once in a
> while, so you not only have to have it installed, but also the right
> version. Beside that SDL_* does things we need, ClanLib and Allegro
> don't.
>
> Last not least I don't consider dependencies a bad thing, if some
> library does what you need, then use it. The solution to the
> dependency problem are binaries (static or with .so's included), no
> recoding the wheel over and over again just to keep the dependencies
> low.

 James enumerated 5 reasons for the use of SDL. My point was just that it i=
s=20
stupid to say that it should be used because everyone has it.

 Anyway, you say dependencies is not a =ABbad thing=BB. You do have to agre=
e, that=20
even if it is in a very small degree, it is not really that good.=20
Dependencies mean bigger binaries, might have portability problems and the=
=20
ask for more maintenance.

Cheers,
 Ricardo

=2D-=20
One evening Mr. Rudolph Block, of New York, found himself seated at dinner
alongside Mr. Percival Pollard, the distinguished critic.
   "Mr. Pollard," said he, "my book, _The Biography of a Dead Cow_, is
 published anonymously, but you can hardly be ignorant of its authorship.
 Yet in reviewing it you speak of it as the work of the Idiot of the Centur=
y.
 Do you think that fair criticism?"
   "I am very sorry, sir," replied the critic, amiably, "but it did not
occur to me that you really might not wish the public to know who wrote it."
=2D- Ambrose Bierce