tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] tuxkart GUI

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

James Gregory <jam...@bt...> writes:

> If you think it would be worth rewriting it all in an OO way, we
> could do that, what do you think?

Rewriting it is certainly not worth it as this point in time, just
having it encapsuled in a class is already more then enough.

I think it would be much more imporant to first get the new GUI into
action before touching gui code itself, ie. create a new start screen
with simple "Start", "Multiplayer", "Quit", move from there to other
screens. See:

http://netpanzer.berlios.de/tuxkart/index.php/User%20Interface

Refactoring the gui code into being more OO can still be relativly
easily be done at a later point when necessary.

> On this note, should I actually use an enum, or just do it via an int
> and lots of #defines as does the rest of the game?

Enum's please, defines are rather evil and unnecesarry in C++, unless
of course you need them for #ifdef's.

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

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. I just wanted to ask what you are working on right now, so that 
> we can somehow work together without too much interference.
> 
> Will we support some sort of config file for the GUI descriptions? I could 
> create a file format and write a parser for it.
> 
> I could also simply start desigining some of the special widgets which 
> we'll need for selecting cars and tracks, or simply start designing some 
> of the screens outlined in the wiki.
> 
> Could you gimme a brief report on the current status of the UI?
> 
> Greetings,
> 	Matze

I started totally rewriting it such that it was all object based and I
had a Widget class from which you derived all GUI stuff, like in ClanLib
or indeed most OO window stuff as far as I can tell. However, I then
decided that this total rewirte probably wasn't worth it, and so my new
design is very similar to the original Neverball (which is pure C).

If you think it would be worth rewriting it all in an OO way, we could
do that, what do you think?

But anyway, the way I'm doing it now adds three globals:

1. widgetSet* of class widget, which is what was the GUI code in
Neverball, except put in a class such that the init function is now a
constructor and the deinit function is now a destructor. In CVS this is
still called gui* of class GUI, but it's not any more. 

2. gui* of class BaseGUI.

3. An enumerated variable that can have a value of (I'm making these
names up on the fly, I've not actually done this yet, so the names will
probably change) GUI_CURRENT, GUI_MAINMENU, GUI_SETKEYS,
GUI_CHOOSETRACK, etc.

On this note, should I actually use an enum, or just do it via an int
and lots of #defines as does the rest of the game?


The way the Neverball GUI code works, you tell widgetSet to create a
widget, and it gives you back an id. You then call WidgetSet functions
when you want to do something with your widgets, giving the id of which
widget you are referring to.

BaseGUI is just a handle class - everything in it is purely virtual.

The idea is each possible menu screen/state derives from BaseGUI, and it
will store a collection of relevant IDs, and have all the code specific
to any particular widgets.

When you want to go to a new stage (i.e. to a different menu screen, or
indeed into the race), you change the value of the global enum to
something other than GUI_CURRENT, and then somewhere in the main loop
gui will be deleted. This calls the destructor of whatever GUI class is
there currently. Each destructor will delete any widgets it has created.
You then say gui = MyGUIClass, and the constructor of MyGUIClass will
set up all the widgets for that screen.

There's still a few minor issues meaning it doesn't compile right now,
and I have to go to bed soon so I can get up at 5 tommorrow morning to
go to work. However, if you give me another day (as in, 24 hours), I
should have it committed.

At that point the basic structure would all be there, and we could then
work on seperate menu screens - e.g., I could do the main menu screen
and the in-race stuff for now, whilst you could do some other menu
screens (e.g. choose character, choose track, configure keys, whatever).
Obviously it will require some coordination such that our menus
interlink correctly.

Unless you want to rewrite it all to be properly OO...

	James

[TuxKart-devel] tuxkart GUI

[Matze B. <ma...@br...>]

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. I just wanted to ask what you are working on right now, so that 
we can somehow work together without too much interference.

Will we support some sort of config file for the GUI descriptions? I could 
create a file format and write a parser for it.

I could also simply start desigining some of the special widgets which 
we'll need for selecting cars and tracks, or simply start designing some 
of the screens outlined in the wiki.

Could you gimme a brief report on the current status of the UI?

Greetings,
	Matze

Re: [TuxKart-devel] Some notes

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

On Mon, 2004-08-02 at 16:16, Matze Braun wrote:

> > As for the issues with not using SDL:
> Hmm this more like issues when forcing ourself to use plib everywhere as 
> much as possible. It's not really an SDL or not discussion.

That's what I meant - by "SDL" I meant "libraries other than plib".

> > 
> > 1. No fullscreen mode
> > 2. GUI-wise being limited to using what plib provides
> We can still create a new GUI without SDL. It should be possible to 
> replace the font and image loading code with plib stuff. (However image 
> loading is a bit problematic since plib seems to only support power-of-2 
> images :-/)

We could do, but why? As you say at the bottom of this reply:

	"not using existing usefull libraries for the sake of keeping
	dependencies down doesn't make much sense"

> > 3. Being limited in terms of file formats to what plib provides (e.g. no
> > use of png, no use of physfs)
> Note that physfs has nothing to do with SDL. 
> The thing that is lacking 
> here is the plib loader API which only supports loading from FILE*. physfs 
> support would be nice but really isn't that crucial for the game.
> 

This is true, this is a minor point - point 1 is most important, then
point 2, then this is just one extra minor one on top.

> > 4. Far more people know how to program using SDL and its sister
> > libraries than know how to use plib
> SDL is no replacement for plib. You need plib for scene graph and 
> model-loading stuff, SDL doesn't provide such things.

I know that, this isn't "SDL vs plib", it's "plib only, therefore
keeping dependencies down vs plib and SDL, therefore not having to
constantly rewrite code that already exists elsewhere".

> > 5. Everyone who ever compiles games already has SDL, SDL_image etc in
> > any case
> 
> Very true, not using existing usefull libraries for the sake of keeping 
> dependencies down doesn't make much sense. As I explained lengthy in the 
> wiki we should concentrate on getting the autoconf stuff right and provide 
> static binaries, so that people will have no trouble with the additional 
> libraries.

I think that makes sense, but I get a rather clear impression that Steve
strongly disagrees - he simply doesn't want TuxKart to use libraries
other than plib, fullstop.

	James

Re: [TuxKart-devel] Some notes

[Matze B. <ma...@br...>]

On Mon, 2 Aug 2004, James Gregory wrote:

> On Mon, 2004-08-02 at 01:01, Charles Goodwin wrote:
> > On Sun, 2004-08-01 at 18:21 -0500, Steve Baker wrote:
> > > James Gregory wrote:
> > > 
> > > > 3. there's no chance it will compile now as I don't know how to change
> > > > the autoconf stuff to make it make a makefile that includes my new
> > > > files. It also now needs to link to SDLimage and SDL_ttf
> > > 
> > > Guys I do not want dependancies on anything outside of PLIB.
> > > 
> > > If you add that shit - I'll just take it right out again when GOTM
> > > goes away.
> > 
> > That was a strong word (the s... one).
> > 
> > Anyway, AFAIK it's all being done with IFDEFS for the moment.  If you
> > can maintain the PLIB side of those IFDEFS then everybody will be happy.
> > The problem is that PLIB doesn't seem to handle things in the way people
> > want/expect and asking questions via the mailing list is just an
> > abysmally slow way to progress when you have lots of questions.
> > 
> > (Perhaps if you hung out on irc just once or twice?)
> > 
> > I don't know the specifics other than fullscreen mode that was, erm,
> > declined more than answered (ie. "go with a borderless window") so it
> > would be useful if James or somebody could go over the various issues
> > that SDL is currently being used to solve.
> > 
> > I'm pretty certain everybody would be happy to use PLIB only if they
> > knew how to, and that SDL can be considered a stop-gap solution until
> > the PLIB aspect is put in, but it's currently needed to aid progress.
> > 
> > At least, that's my take on it.
> 
> No, it will not longer compile without SDL, whatever IFDEFS you use.
> 
> Steve, it's your CVS, so take it out if you want. Alternatively, I've
> got lots of free time right now, so if you want I can download the
> pre-GOTM version and commit it for you.
> 
> However, I don't think many people will want to work on it as the GOTM
> project if we can only use PLIB. Maybe it would be worth doing a GOTM
> fork? Or maybe not. What do other people think?
> 
> As for the issues with not using SDL:
Hmm this more like issues when forcing ourself to use plib everywhere as 
much as possible. It's not really an SDL or not discussion.

> 
> 1. No fullscreen mode
> 2. GUI-wise being limited to using what plib provides
We can still create a new GUI without SDL. It should be possible to 
replace the font and image loading code with plib stuff. (However image 
loading is a bit problematic since plib seems to only support power-of-2 
images :-/)

> 3. Being limited in terms of file formats to what plib provides (e.g. no
> use of png, no use of physfs)
Note that physfs has nothing to do with SDL. The thing that is lacking 
here is the plib loader API which only supports loading from FILE*. physfs 
support would be nice but really isn't that crucial for the game.

> 4. Far more people know how to program using SDL and its sister
> libraries than know how to use plib
SDL is no replacement for plib. You need plib for scene graph and 
model-loading stuff, SDL doesn't provide such things.

> 5. Everyone who ever compiles games already has SDL, SDL_image etc in
> any case

Very true, not using existing usefull libraries for the sake of keeping 
dependencies down doesn't make much sense. As I explained lengthy in the 
wiki we should concentrate on getting the autoconf stuff right and provide 
static binaries, so that people will have no trouble with the additional 
libraries.

Greetings,
	Matze

Re: [TuxKart-devel] cvs access

[Matze B. <ma...@br...>]

Thanks

On Sun, 1 Aug 2004, Steve Baker wrote:

> Matze Braun wrote:
> 
> > could have cvs access please? My sourceforge name is "matzebraun".
> 
> Done!
> 
> Welcome to the team.
> 
> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>             http://tuxkart.sf.net http://prettypoly.sf.net
> -----BEGIN GEEK CODE BLOCK-----
> GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
> -----END GEEK CODE BLOCK-----
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
> 
> 

Re: [TuxKart-devel] Some notes

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

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.

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

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

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

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

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

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

Re: [TuxKart-devel] Some notes

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

 Let me throw my 2 cents about this SDL issue.

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.

> 2. GUI-wise being limited to using what plib provides
 I believe it is as rich as ClanLib GUI module and other GUI libraries.

 But even if we decide to do a custom GUI code, can't we use its image and 
text capabilities?

> 3. Being limited in terms of file formats to what plib provides (e.g. no
> use of png, no use of physfs)
 About PNGs, isn't JPEG supported? If yes, should be used. Files are even 
smaller with it.

 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.

> 4. Far more people know how to program using SDL and its sister
> libraries than know how to use plib
 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.

> 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

Sorry for anything stupid,

 Ricardo

> 	James
>
>

-- 
When a place gets crowded enough to require ID's, social collapse is not
far away.  It is time to go elsewhere.  The best thing about space travel
is that it made it possible to go elsewhere.
		-- R.A. Heinlein, "Time Enough For Love"

Re: [TuxKart-devel] Some notes

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

On Mon, 2004-08-02 at 03:00 +0100, James Gregory wrote:
> No, it will not longer compile without SDL, whatever IFDEFS you use.
> 
> Steve, it's your CVS, so take it out if you want. Alternatively, I've
> got lots of free time right now, so if you want I can download the
> pre-GOTM version and commit it for you.
> 
> However, I don't think many people will want to work on it as the GOTM
> project if we can only use PLIB. Maybe it would be worth doing a GOTM
> fork? Or maybe not. What do other people think?

I would really strongly recommend _against_ a GotM fork.  Besides the
fact that it would mean a new game to maintain (who'll be doing that?)
it also completely goes against the spirit of GotM.

I'm hoping Steve will let things slide for the moment, and phase out SDL
once GotM is over so that TuxKart gets the GotM benefits (lotsa TuxKart
goodness) and he only gets a little hassle (the SDL->PLIB issue) for
those benefits.

> As for the issues with not using SDL:
> 
> 1. No fullscreen mode
> 2. GUI-wise being limited to using what plib provides
> 3. Being limited in terms of file formats to what plib provides (e.g. no
> use of png, no use of physfs)

What could you do about these, Steve?

I completely understand, and even agree, with the desire to stick with
pure PLIB.  Is it acceptable to simply (or not so simply) unSDL things
later on once GotM has passed and TuxKart has benefited?
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] Some notes

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

On Mon, 2004-08-02 at 01:41, Matze Braun wrote:
> On Sun, 1 Aug 2004, James Gregory wrote:
> 
> > 1. The new loading code means that the game only works if the exe is run
> > from the game's root directory. I've changed some of the loading stuff
> > to use the Loader class to fix this, but not all of it.
> Huh? I added several searchpaths in start_tuxkart.cxx, so tuxkart should 
> also run from other directories. I'm planing to do add some code that 
> determines the directory of the executable (/proc/self...) so that it is 
> even more smart than just adding . and TUXKART_DATADIR.

It can't find the image files.

> > 2. In tuxkart.cxx there are lines like "loader ->
> > setCreateStateCallback  ( getAppState ) ;", which made sense before but
> > I don't think it does now that "loader" is something entirely different?
> No, the loader is still a subclass of ssgLoaderOptions, so the plib 
> related stuff is still valid and correct.

Oh, OK, sorry.

> > 
> > 3. there's no chance it will compile now as I don't know how to change
> > the autoconf stuff to make it make a makefile that includes my new
> > files. It also now needs to link to SDLimage and SDL_ttf
> 
> Are you talking about the GUI code?
> 

Yup, though grumbel changed the make stuff so it will compile now (and
has done for some hours)...if you have the right libraries installed.

	James

Re: [TuxKart-devel] Some notes

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

On Mon, 2004-08-02 at 01:01, Charles Goodwin wrote:
> On Sun, 2004-08-01 at 18:21 -0500, Steve Baker wrote:
> > James Gregory wrote:
> > 
> > > 3. there's no chance it will compile now as I don't know how to change
> > > the autoconf stuff to make it make a makefile that includes my new
> > > files. It also now needs to link to SDLimage and SDL_ttf
> > 
> > Guys I do not want dependancies on anything outside of PLIB.
> > 
> > If you add that shit - I'll just take it right out again when GOTM
> > goes away.
> 
> That was a strong word (the s... one).
> 
> Anyway, AFAIK it's all being done with IFDEFS for the moment.  If you
> can maintain the PLIB side of those IFDEFS then everybody will be happy.
> The problem is that PLIB doesn't seem to handle things in the way people
> want/expect and asking questions via the mailing list is just an
> abysmally slow way to progress when you have lots of questions.
> 
> (Perhaps if you hung out on irc just once or twice?)
> 
> I don't know the specifics other than fullscreen mode that was, erm,
> declined more than answered (ie. "go with a borderless window") so it
> would be useful if James or somebody could go over the various issues
> that SDL is currently being used to solve.
> 
> I'm pretty certain everybody would be happy to use PLIB only if they
> knew how to, and that SDL can be considered a stop-gap solution until
> the PLIB aspect is put in, but it's currently needed to aid progress.
> 
> At least, that's my take on it.

No, it will not longer compile without SDL, whatever IFDEFS you use.

Steve, it's your CVS, so take it out if you want. Alternatively, I've
got lots of free time right now, so if you want I can download the
pre-GOTM version and commit it for you.

However, I don't think many people will want to work on it as the GOTM
project if we can only use PLIB. Maybe it would be worth doing a GOTM
fork? Or maybe not. What do other people think?

As for the issues with not using SDL:

1. No fullscreen mode
2. GUI-wise being limited to using what plib provides
3. Being limited in terms of file formats to what plib provides (e.g. no
use of png, no use of physfs)
4. Far more people know how to program using SDL and its sister
libraries than know how to use plib
5. Everyone who ever compiles games already has SDL, SDL_image etc in
any case

	James

Re: [TuxKart-devel] Some notes

[Matze B. <ma...@br...>]

On Sun, 1 Aug 2004, James Gregory wrote:

> 1. The new loading code means that the game only works if the exe is run
> from the game's root directory. I've changed some of the loading stuff
> to use the Loader class to fix this, but not all of it.
Huh? I added several searchpaths in start_tuxkart.cxx, so tuxkart should 
also run from other directories. I'm planing to do add some code that 
determines the directory of the executable (/proc/self...) so that it is 
even more smart than just adding . and TUXKART_DATADIR.

> 
> 2. In tuxkart.cxx there are lines like "loader ->
> setCreateStateCallback  ( getAppState ) ;", which made sense before but
> I don't think it does now that "loader" is something entirely different?
No, the loader is still a subclass of ssgLoaderOptions, so the plib 
related stuff is still valid and correct.

> 
> 3. there's no chance it will compile now as I don't know how to change
> the autoconf stuff to make it make a makefile that includes my new
> files. It also now needs to link to SDLimage and SDL_ttf

Are you talking about the GUI code?

Greetings,
	Matze

Re: [TuxKart-devel] Some notes

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

On Sun, 2004-08-01 at 18:21 -0500, Steve Baker wrote:
> James Gregory wrote:
> 
> > 3. there's no chance it will compile now as I don't know how to change
> > the autoconf stuff to make it make a makefile that includes my new
> > files. It also now needs to link to SDLimage and SDL_ttf
> 
> Guys I do not want dependancies on anything outside of PLIB.
> 
> If you add that shit - I'll just take it right out again when GOTM
> goes away.

That was a strong word (the s... one).

Anyway, AFAIK it's all being done with IFDEFS for the moment.  If you
can maintain the PLIB side of those IFDEFS then everybody will be happy.
The problem is that PLIB doesn't seem to handle things in the way people
want/expect and asking questions via the mailing list is just an
abysmally slow way to progress when you have lots of questions.

(Perhaps if you hung out on irc just once or twice?)

I don't know the specifics other than fullscreen mode that was, erm,
declined more than answered (ie. "go with a borderless window") so it
would be useful if James or somebody could go over the various issues
that SDL is currently being used to solve.

I'm pretty certain everybody would be happy to use PLIB only if they
knew how to, and that SDL can be considered a stop-gap solution until
the PLIB aspect is put in, but it's currently needed to aid progress.

At least, that's my take on it.
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] Some notes

[Steve B. <sjb...@ai...>]

James Gregory wrote:

> 3. there's no chance it will compile now as I don't know how to change
> the autoconf stuff to make it make a makefile that includes my new
> files. It also now needs to link to SDLimage and SDL_ttf

Guys I do not want dependancies on anything outside of PLIB.

If you add that shit - I'll just take it right out again when GOTM
goes away.

I don't want the hassle of maintaining it and it flat out isn't necessary.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[TuxKart-devel] Some notes

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

1. The new loading code means that the game only works if the exe is run
from the game's root directory. I've changed some of the loading stuff
to use the Loader class to fix this, but not all of it.

2. In tuxkart.cxx there are lines like "loader ->
setCreateStateCallback  ( getAppState ) ;", which made sense before but
I don't think it does now that "loader" is something entirely different?

3. there's no chance it will compile now as I don't know how to change
the autoconf stuff to make it make a makefile that includes my new
files. It also now needs to link to SDLimage and SDL_ttf

	James

Re: [TuxKart-devel] cvs access

[Steve B. <sjb...@ai...>]

Matze Braun wrote:

> could have cvs access please? My sourceforge name is "matzebraun".

Done!

Welcome to the team.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] FTBFS from CVS

[Steve B. <sjb...@ai...>]

Ryan Flegel wrote:
> On Fri, 30 Jul 2004 20:58:41 -0400, Pascal Giard
> <pa...@gu...> wrote:
>=20
>>Hi grumbel,
>>
>>after you're modifs i FTBFS=B9. Here's the relevant output:
>=20
>=20
> Try:
>   make clean
>   ./autogen.sh
>   ./configure
>   make
>=20
> since there were changes to the autoconf/automake files.

Or better still:

    ./reconf

=2E..which does everything.

You should always do this following a 'checkout'.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++=

-----END GEEK CODE BLOCK-----

[TuxKart-devel] cvs access

[Matze B. <ma...@br...>]

Hi,

could have cvs access please? My sourceforge name is "matzebraun".

I would work on getting animations for the characters.

Greetings,
	Matze

Re: [TuxKart-devel] Could I possibly have CVS access, Steve?

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

On Sat, 2004-07-31 at 00:35, Steve Baker wrote:
> James Gregory wrote:
> > On Fri, 2004-07-30 at 21:58, Steve Baker wrote:
> > 
> >>James Gregory wrote:
> >>
> >>>Thanks,
> >>
> >>I need your sourceforge account name.
> > 
> > 
> > jamesgregory
> 
> Welcome to the team!  You should have CVS access now.
> 

Thanks!

	James

Re: [TuxKart-devel] screensize is broken

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

On Sat, 2004-07-31 at 09:38, Pascal Giard wrote:
> Hi again grumbel,
>  with your latest update in start_tuxkart.cxx, you've broken the sreensize
> cmdline feature... did you do it on purpose ? (if so why ?)
> 

Fixed...

	James

[TuxKart-devel] screensize is broken

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

Hi again grumbel,
 with your latest update in start_tuxkart.cxx, you've broken the sreensize
cmdline feature... did you do it on purpose ? (if so why ?)

-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] FTBFS from CVS

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

> Try:
>   make clean
>   ./autogen.sh
>   ./configure
>   make
> 
> since there were changes to the autoconf/automake files.

hehhe, /me feels stupid...
actually, i was missing the "-I m4" to aclocal.

-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] FTBFS from CVS

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

On Fri, 30 Jul 2004 20:58:41 -0400, Pascal Giard
<pa...@gu...> wrote:
> Hi grumbel,
>=20
> after you're modifs i FTBFS=B9. Here's the relevant output:

Try:
  make clean
  ./autogen.sh
  ./configure
  make

since there were changes to the autoconf/automake files.

--=20
Ryan

[TuxKart-devel] FTBFS from CVS

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

Hi grumbel,

after you're modifs i FTBFS¹. Here's the relevant output:

g++  -g -O2 -I/usr/include/SDL -D_REENTRANT -O6 -Wall   -o tuxkart  sdldrv.o
AutoDriver.o Camera.o Driver.o Explosion.o Herring.o KartDriver.o
PlayerDriver.o Projectile.o Track.o Traffic.o guNet.o isect.o loader.o sound.o
utils.o gfx.o gui.o material.o preprocessor.o start_tuxkart.o status.o
tuxkart.o  -lplibjs -lplibsl -lplibssg -lplibpu -lplibfnt -lplibsg -lplibpw
-lplibul -lGL  -lSDL -lpthread  -L/usr/X11R6/lib  -lSM -lICE -lpthread -lX11
-lXi -lXext -lXmu  -lm
sdldrv.o(.text+0x54c): dans la fonction « keyboardInput(SDL_keysym const&)»:
/home/evilynux/CVS/tuxkart/src/sdldrv.cxx:118: undefined reference to
`PlayerKartDriver::incomingKeystroke(SDL_keysym const&)'
gui.o(.text+0x7ed): dans la fonction « GUI::keyboardInput()     »:
/home/evilynux/CVS/tuxkart/src/gui.cxx:126: undefined reference to
`getKeystroke()'
gui.o(.text+0xb1a): dans la fonction « GUI::joystickInput()     »:
/home/evilynux/CVS/tuxkart/src/gui.cxx:198: undefined reference to
`isKeyDown(unsigned)'
gui.o(.text+0xb35):/home/evilynux/CVS/tuxkart/src/gui.cxx:199: undefined
reference to `isKeyDown(unsigned)'
gui.o(.text+0xb50):/home/evilynux/CVS/tuxkart/src/gui.cxx:200: undefined
reference to `isKeyDown(unsigned)'
gui.o(.text+0xb67):/home/evilynux/CVS/tuxkart/src/gui.cxx:201: undefined
reference to `isKeyDown(unsigned)'
gui.o(.text+0xb7e):/home/evilynux/CVS/tuxkart/src/gui.cxx:203: undefined
reference to `isKeyDown(unsigned)'
gui.o(.text+0xb99):/home/evilynux/CVS/tuxkart/src/gui.cxx:205: more undefined
references to `isKeyDown(unsigned)' follow
tuxkart.o(.text+0xfff): dans la fonction « tuxkartMain(int, int, int, char*,
int)»:
/home/evilynux/CVS/tuxkart/src/tuxkart.cxx:464: undefined reference to
`mousefn(int, int, int, int)'
tuxkart.o(.text+0x1013):/home/evilynux/CVS/tuxkart/src/tuxkart.cxx:464:
undefined reference to `reshape(int, int)'
tuxkart.o(.text+0x1018):/home/evilynux/CVS/tuxkart/src/tuxkart.cxx:464:
undefined reference to `motionfn(int, int)'
tuxkart.o(.text+0x102b):/home/evilynux/CVS/tuxkart/src/tuxkart.cxx:464:
undefined reference to `keystroke(int, int, int, int)'
collect2: ld a retourné 1 code d'état d'exécution


I also noticed that you removed fullscreen for non-SDL users and that you
forgot to removed --no-borders from the help message.

As a debian user, i don't care about the SDL dependency in order to play
fullscreen, but others might enjoy to be able to play fullscreen w/o SDL.
If it's not easily fixable/doable, forget it.

-Pascal
¹ http://www.webster-dictionary.org/definition/FTBFS
--
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] Could I possibly have CVS access, Steve?

[Steve B. <sjb...@ai...>]

James Gregory wrote:
> On Fri, 2004-07-30 at 21:58, Steve Baker wrote:
> 
>>James Gregory wrote:
>>
>>>Thanks,
>>
>>I need your sourceforge account name.
> 
> 
> jamesgregory

Welcome to the team!  You should have CVS access now.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----