tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] Slowness - really related with Karts?

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

> Modified Files:
>       RaceGUI.cxx RaceGUI.h 
> Log Message:
> - fixed the computer-killer bug: each time text was drawn in RaceGUI 
> a new OpenGL texture was created but never freed. This has been 
> fixed by freeing the textures created each frame. Possibly some sort 
> of cache of textures would be more efficient, but this at least 
> makes the game runnable again.

 Ooops. Looks like it was my fault afterall... And I trying to blame another 
guy... :P
 Anyway, I guess this was a good opportunity for an auditory checking and 
fixing of others memory leaks, so it was a good thing, afterall. :)

 About the cache of textures, that is not practicable, since text is different 
all the time. You'd need tons of memory to cache all different combinations 
of texts.
 What I currently do is to cache TTF_Font, which already helps speeding it up. 
Though, I dunno if TTF_OpenFont() is all that expensive.

 By the way, Ingo, the game is outputting this:

WARNING: ssgSGIHeader::: Failed to open 
'NotFound: /home/ingo/projects/tuxkart/cvs/images/tuxkarttex.rgb' for 
reading.
WARNING: ssgSGIHeader::: Failed to open 
'NotFound: /home/ingo/projects/tuxkart/cvs/images/tuxtex.rgb' for reading.
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/bonusblock.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/bonusblock.png
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/banana.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/banana.png
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/stonetex.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/stonetex.png
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/trackborder.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/trackborder.png
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/models/palm.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/models/palm.png
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/models/palmtree.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/models/palmtree.png
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/water.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/water.png
WARNING: ssgLoadPNG: Failed to load 
'NotFound: /home/ingo/projects/tuxkart/stonegrass.png': Couldn't open 
NotFound: /home/ingo/projects/tuxkart/stonegrass.png
Fatal signal: Segmentation Fault (SDL Parachute Deployed)


Cheers,
 Ricardo

Em Domingo, 5 de Setembro de 2004 21:45, o Ricardo Cruz escreveu:
> Hello,
>
>  I've done some investigation and I'm positive the main leak (there might
> be others) is on widget_image.cxx. make_image_from_font() or any other
> function it uses is most likely leaking.
>  I've already coded another make_image_from_surface(), but the problem
> prevails. I really dunno where the leak is, but I believe it's from there
> somewhere.
>
> Cheers,
>  Ricardo
>
> Em Domingo, 5 de Setembro de 2004 17:37, o James Gregory escreveu:
> > Does anyone know where to start looking for whatever the show-stopping
> > problem in the tuxkart cvs is right now?
> >
> > It's pretty frustrating trying to find out what the problem is as each
> > time I run tuxkart I have to reboot my computer.
> >
> > cvs -z3 history -a -e -D "8 days ago" gives:
> >
> > U 2004-09-02 04:17 +0000 evilynux     1.1  Player.cxx
> > tuxkart/src     == <remote>/src
> > U 2004-09-02 04:17 +0000 evilynux     1.1  Player.h
> > tuxkart/src     == <remote>/src
> > M 2004-08-28 16:35 +0000 jamesgregory 1.4  gownsbow.track
> > tuxkart/data    == <remote>
> > M 2004-08-28 16:35 +0000 jamesgregory 1.4  startrack.track
> > tuxkart/data    == <remote>
> > M 2004-08-29 00:55 +0000 jamesgregory 1.5  ConfigControls.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-08-29 00:55 +0000 jamesgregory 1.9  NumPlayers.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-08-29 00:55 +0000 jamesgregory 1.7  Options.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-08-29 00:55 +0000 jamesgregory 1.3  PlayerControls.cxx
> > tuxkart/src/gui == <remote>
> > U 2004-09-01 18:32 +0000 jamesgregory 1.1  Player.cxx
> > tuxkart/src     == <remote>/src
> > U 2004-09-01 18:32 +0000 jamesgregory 1.1  Player.h
> > tuxkart/src     == <remote>/src
> > U 2004-09-05 13:42 +0000 jamesgregory 1.10 StartScreen.cxx
> > tuxkart/src     == <remote>
> > U 2004-09-05 13:45 +0000 jamesgregory 1.35 sdldrv.cxx
> > tuxkart/src     == <remote>
> > G 2004-08-29 10:24 +0000 matzebraun   1.36 Driver.cxx
> > tuxkart/src     == <remote>/src
> > U 2004-09-02 14:18 +0000 matzebraun   1.1  Player.cxx
> > tuxkart/src     == <remote>/src
> > U 2004-09-02 14:18 +0000 matzebraun   1.1  Player.h
> > tuxkart/src     == <remote>/src
> > G 2004-09-04 12:46 +0000 matzebraun   1.35 RaceGUI.cxx
> > tuxkart/src/gui == <remote>/src/gui
> > O 2004-08-28 21:39 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > M 2004-08-28 22:05 +0000 oaf_thadres  1.5  Config.cxx
> > tuxkart/src     == <remote>
> > M 2004-08-28 22:05 +0000 oaf_thadres  1.3  Config.h
> > tuxkart/src     == <remote>
> > M 2004-08-28 22:05 +0000 oaf_thadres  1.47 KartDriver.cxx
> > tuxkart/src     == <remote>
> > M 2004-08-28 22:22 +0000 oaf_thadres  1.7  sound.cxx
> > tuxkart/src     == <remote>
> > M 2004-08-28 22:22 +0000 oaf_thadres  1.6  sound.h
> > tuxkart/src     == <remote>
> > M 2004-08-28 22:41 +0000 oaf_thadres  1.77 start_tuxkart.cxx
> > tuxkart/src     == <remote>
> > O 2004-08-29 17:38 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-08-29 19:41 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-08-29 19:49 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > M 2004-08-29 19:50 +0000 oaf_thadres  1.6  Config.cxx
> > tuxkart/src     == <remote>
> > M 2004-08-29 19:50 +0000 oaf_thadres  1.4  Config.h
> > tuxkart/src     == <remote>
> > M 2004-08-29 19:50 +0000 oaf_thadres  1.39 Makefile.am
> > tuxkart/src     == <remote>
> > M 2004-08-29 19:50 +0000 oaf_thadres  1.35 sdldrv.cxx
> > tuxkart/src     == <remote>
> > M 2004-08-29 19:50 +0000 oaf_thadres  1.12 sdldrv.h
> > tuxkart/src     == <remote>
> > M 2004-08-29 19:50 +0000 oaf_thadres  1.4  PlayerControls.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-08-29 19:50 +0000 oaf_thadres  1.3  PlayerControls.h
> > tuxkart/src/gui == <remote>
> > O 2004-08-30 03:02 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-09-01 02:17 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > M 2004-09-01 02:21 +0000 oaf_thadres  1.7  Config.cxx
> > tuxkart/src     == <remote>
> > A 2004-09-01 02:21 +0000 oaf_thadres  1.1  Player.cxx
> > tuxkart/src     == <remote>
> > A 2004-09-01 02:21 +0000 oaf_thadres  1.1  Player.h
> > tuxkart/src     == <remote>
> > O 2004-09-01 14:17 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-09-02 04:19 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-09-02 22:00 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-09-03 13:24 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-09-05 02:44 +0000 oaf_thadres  tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-08-29 16:25 +0000 rmcruz       tuxkart         =tuxkart=
> > <remote>/*
> > M 2004-08-29 17:24 +0000 rmcruz       1.30 RaceGUI.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-08-29 17:24 +0000 rmcruz       1.8  RaceGUI.h
> > tuxkart/src/gui == <remote>
> > O 2004-08-30 20:59 +0000 rmcruz       tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-08-31 17:45 +0000 rmcruz       tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-09-01 11:43 +0000 rmcruz       tuxkart         =tuxkart=
> > <remote>/*
> > O 2004-09-01 11:56 +0000 rmcruz       tuxkart         =tuxkart=
> > <remote>/*
> > M 2004-09-01 15:22 +0000 rmcruz       1.31 RaceGUI.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-09-01 15:22 +0000 rmcruz       1.9  RaceGUI.h
> > tuxkart/src/gui == <remote>
> > M 2004-09-01 21:45 +0000 rmcruz       1.32 RaceGUI.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-09-01 21:45 +0000 rmcruz       1.10 RaceGUI.h
> > tuxkart/src/gui == <remote>
> > M 2004-09-01 22:15 +0000 rmcruz       1.33 RaceGUI.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-09-01 22:15 +0000 rmcruz       1.11 RaceGUI.h
> > tuxkart/src/gui == <remote>
> > M 2004-09-02 13:48 +0000 rmcruz       1.34 RaceGUI.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-09-02 13:48 +0000 rmcruz       1.12 RaceGUI.h
> > tuxkart/src/gui == <remote>
> > O 2004-09-03 11:11 +0000 rmcruz       tuxkart         =tuxkart=
> > <remote>/*
> > M 2004-09-04 11:17 +0000 rmcruz       1.35 RaceGUI.cxx
> > tuxkart/src/gui == <remote>
> > M 2004-09-04 11:17 +0000 rmcruz       1.13 RaceGUI.h
> > tuxkart/src/gui == <remote>
> > O 2004-09-04 14:34 +0000 rmcruz       tuxkart         =tuxkart=
> > <remote>/*
> >
> > At what point did it stop working?
> > To summarise the above, the people who have edited tuxkart most
> > recently, most recent edit last, are:
> >
> > evilynux
> > jamesgregory
> > maztebraun
> > oaf_thadres
> > rmcruz
> >
> > 	James
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> > _______________________________________________
> > Tuxkart-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxkart-devel

-- 
For children with short attention spans: boomerangs that don't come back.

Re: [TuxKart-devel] Slowness - really related with Karts?

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

Hello,

 I've done some investigation and I'm positive the main leak (there might be 
others) is on widget_image.cxx. make_image_from_font() or any other function 
it uses is most likely leaking.
 I've already coded another make_image_from_surface(), but the problem 
prevails. I really dunno where the leak is, but I believe it's from there 
somewhere.

Cheers,
 Ricardo

Em Domingo, 5 de Setembro de 2004 17:37, o James Gregory escreveu:
> Does anyone know where to start looking for whatever the show-stopping
> problem in the tuxkart cvs is right now?
>
> It's pretty frustrating trying to find out what the problem is as each
> time I run tuxkart I have to reboot my computer.
>
> cvs -z3 history -a -e -D "8 days ago" gives:
>
> U 2004-09-02 04:17 +0000 evilynux     1.1  Player.cxx
> tuxkart/src     == <remote>/src
> U 2004-09-02 04:17 +0000 evilynux     1.1  Player.h
> tuxkart/src     == <remote>/src
> M 2004-08-28 16:35 +0000 jamesgregory 1.4  gownsbow.track
> tuxkart/data    == <remote>
> M 2004-08-28 16:35 +0000 jamesgregory 1.4  startrack.track
> tuxkart/data    == <remote>
> M 2004-08-29 00:55 +0000 jamesgregory 1.5  ConfigControls.cxx
> tuxkart/src/gui == <remote>
> M 2004-08-29 00:55 +0000 jamesgregory 1.9  NumPlayers.cxx
> tuxkart/src/gui == <remote>
> M 2004-08-29 00:55 +0000 jamesgregory 1.7  Options.cxx
> tuxkart/src/gui == <remote>
> M 2004-08-29 00:55 +0000 jamesgregory 1.3  PlayerControls.cxx
> tuxkart/src/gui == <remote>
> U 2004-09-01 18:32 +0000 jamesgregory 1.1  Player.cxx
> tuxkart/src     == <remote>/src
> U 2004-09-01 18:32 +0000 jamesgregory 1.1  Player.h
> tuxkart/src     == <remote>/src
> U 2004-09-05 13:42 +0000 jamesgregory 1.10 StartScreen.cxx
> tuxkart/src     == <remote>
> U 2004-09-05 13:45 +0000 jamesgregory 1.35 sdldrv.cxx
> tuxkart/src     == <remote>
> G 2004-08-29 10:24 +0000 matzebraun   1.36 Driver.cxx
> tuxkart/src     == <remote>/src
> U 2004-09-02 14:18 +0000 matzebraun   1.1  Player.cxx
> tuxkart/src     == <remote>/src
> U 2004-09-02 14:18 +0000 matzebraun   1.1  Player.h
> tuxkart/src     == <remote>/src
> G 2004-09-04 12:46 +0000 matzebraun   1.35 RaceGUI.cxx
> tuxkart/src/gui == <remote>/src/gui
> O 2004-08-28 21:39 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> M 2004-08-28 22:05 +0000 oaf_thadres  1.5  Config.cxx
> tuxkart/src     == <remote>
> M 2004-08-28 22:05 +0000 oaf_thadres  1.3  Config.h
> tuxkart/src     == <remote>
> M 2004-08-28 22:05 +0000 oaf_thadres  1.47 KartDriver.cxx
> tuxkart/src     == <remote>
> M 2004-08-28 22:22 +0000 oaf_thadres  1.7  sound.cxx
> tuxkart/src     == <remote>
> M 2004-08-28 22:22 +0000 oaf_thadres  1.6  sound.h
> tuxkart/src     == <remote>
> M 2004-08-28 22:41 +0000 oaf_thadres  1.77 start_tuxkart.cxx
> tuxkart/src     == <remote>
> O 2004-08-29 17:38 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-08-29 19:41 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-08-29 19:49 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> M 2004-08-29 19:50 +0000 oaf_thadres  1.6  Config.cxx
> tuxkart/src     == <remote>
> M 2004-08-29 19:50 +0000 oaf_thadres  1.4  Config.h
> tuxkart/src     == <remote>
> M 2004-08-29 19:50 +0000 oaf_thadres  1.39 Makefile.am
> tuxkart/src     == <remote>
> M 2004-08-29 19:50 +0000 oaf_thadres  1.35 sdldrv.cxx
> tuxkart/src     == <remote>
> M 2004-08-29 19:50 +0000 oaf_thadres  1.12 sdldrv.h
> tuxkart/src     == <remote>
> M 2004-08-29 19:50 +0000 oaf_thadres  1.4  PlayerControls.cxx
> tuxkart/src/gui == <remote>
> M 2004-08-29 19:50 +0000 oaf_thadres  1.3  PlayerControls.h
> tuxkart/src/gui == <remote>
> O 2004-08-30 03:02 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-09-01 02:17 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> M 2004-09-01 02:21 +0000 oaf_thadres  1.7  Config.cxx
> tuxkart/src     == <remote>
> A 2004-09-01 02:21 +0000 oaf_thadres  1.1  Player.cxx
> tuxkart/src     == <remote>
> A 2004-09-01 02:21 +0000 oaf_thadres  1.1  Player.h
> tuxkart/src     == <remote>
> O 2004-09-01 14:17 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-09-02 04:19 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-09-02 22:00 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-09-03 13:24 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-09-05 02:44 +0000 oaf_thadres  tuxkart         =tuxkart=
> <remote>/*
> O 2004-08-29 16:25 +0000 rmcruz       tuxkart         =tuxkart=
> <remote>/*
> M 2004-08-29 17:24 +0000 rmcruz       1.30 RaceGUI.cxx
> tuxkart/src/gui == <remote>
> M 2004-08-29 17:24 +0000 rmcruz       1.8  RaceGUI.h
> tuxkart/src/gui == <remote>
> O 2004-08-30 20:59 +0000 rmcruz       tuxkart         =tuxkart=
> <remote>/*
> O 2004-08-31 17:45 +0000 rmcruz       tuxkart         =tuxkart=
> <remote>/*
> O 2004-09-01 11:43 +0000 rmcruz       tuxkart         =tuxkart=
> <remote>/*
> O 2004-09-01 11:56 +0000 rmcruz       tuxkart         =tuxkart=
> <remote>/*
> M 2004-09-01 15:22 +0000 rmcruz       1.31 RaceGUI.cxx
> tuxkart/src/gui == <remote>
> M 2004-09-01 15:22 +0000 rmcruz       1.9  RaceGUI.h
> tuxkart/src/gui == <remote>
> M 2004-09-01 21:45 +0000 rmcruz       1.32 RaceGUI.cxx
> tuxkart/src/gui == <remote>
> M 2004-09-01 21:45 +0000 rmcruz       1.10 RaceGUI.h
> tuxkart/src/gui == <remote>
> M 2004-09-01 22:15 +0000 rmcruz       1.33 RaceGUI.cxx
> tuxkart/src/gui == <remote>
> M 2004-09-01 22:15 +0000 rmcruz       1.11 RaceGUI.h
> tuxkart/src/gui == <remote>
> M 2004-09-02 13:48 +0000 rmcruz       1.34 RaceGUI.cxx
> tuxkart/src/gui == <remote>
> M 2004-09-02 13:48 +0000 rmcruz       1.12 RaceGUI.h
> tuxkart/src/gui == <remote>
> O 2004-09-03 11:11 +0000 rmcruz       tuxkart         =tuxkart=
> <remote>/*
> M 2004-09-04 11:17 +0000 rmcruz       1.35 RaceGUI.cxx
> tuxkart/src/gui == <remote>
> M 2004-09-04 11:17 +0000 rmcruz       1.13 RaceGUI.h
> tuxkart/src/gui == <remote>
> O 2004-09-04 14:34 +0000 rmcruz       tuxkart         =tuxkart=
> <remote>/*
>
> At what point did it stop working?
> To summarise the above, the people who have edited tuxkart most
> recently, most recent edit last, are:
>
> evilynux
> jamesgregory
> maztebraun
> oaf_thadres
> rmcruz
>
> 	James
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel

-- 
	A New York City judge ruled that if two women behind you at the
movies insist on discussing the probable outcome of the film, you have the
right to turn around and blow a Bronx cheer at them.

[TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src/gui RaceGUI.cxx,1.35,1.36 RaceGUI.h,1.13,1.14

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

On Sun, 05 Sep 2004 19:05:08 +0000, tuxkart-cvs-admin wrote
> Update of /cvsroot/tuxkart/tuxkart/src/gui
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15225/src/gui
> 
> Modified Files:
> 	RaceGUI.cxx RaceGUI.h 
> Log Message:
> - fixed the computer-killer bug: each time text was drawn in RaceGUI 
> a new OpenGL texture was created but never freed. This has been 
> fixed by freeing the textures created each frame. Possibly some sort 
> of cache of textures would be more efficient, but this at least 
> makes the game runnable again.

indeed, it's very playable again!

Good job!!

-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] Slowness - really related with Karts?

[James G. <j....@vi...>]

On Sun, 2004-09-05 at 18:13, James Gregory wrote:
> On Sun, 2004-09-05 at 17:37, James Gregory wrote:
> 
> > At what point did it stop working?
> > To summarise the above, the people who have edited tuxkart most
> > recently, most recent edit last, are:
> > 
> > evilynux
> > jamesgregory
> > maztebraun
> > oaf_thadres
> > rmcruz
> > 
> 
> Actually I wrongly assumed they were sorted by date, actually the
> entries are only sorted by date for each user, by the look of it the
> users are sorted alphabetically.

Furthermore, evilynux's only entries are updates.

	James

Re: [TuxKart-devel] Slowness - really related with Karts?

[James G. <j....@vi...>]

On Sun, 2004-09-05 at 17:37, James Gregory wrote:

> At what point did it stop working?
> To summarise the above, the people who have edited tuxkart most
> recently, most recent edit last, are:
> 
> evilynux
> jamesgregory
> maztebraun
> oaf_thadres
> rmcruz
> 

Actually I wrongly assumed they were sorted by date, actually the
entries are only sorted by date for each user, by the look of it the
users are sorted alphabetically.

	James

Re: [TuxKart-devel] Valgrind: hunting possible leaks

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

On Sat, 4 Sep 2004, Pascal Giard wrote:

> On Sat, 4 Sep 2004 14:45:17 +0200 (CEST), Matze Braun wrote
> > valgrind has problems with some hacks the nvidia and ati opengl 
> > drivers are doing. An "export __GL_FORCE_GENERIC_CPU=1" helps for 
> > nvidia cards, for ati you can only try to link tuxkart with mesa 
> > instead of ati opengl.
> 
> I've an nVidia, i've just tried __GL_FORCE_GENERIC_CPU=1, but i don't see any
> difference. They're still alot of false positives in
> /usr/lib/tls/libGL.so.1.0.5336.
> 
> 
> > > I'll try kcachegrind to see if i can get to understand more.
> > cachegrind is for testing the performance of an App when you 
> > consider cpu caches so that you can optimize your code to better fit 
> > inside the data and command-caches of the cpu. That's only usefull 
> > if you need to tweak the last 5% performance of your app, we're not 
> > at that point in tuxkart yet.
> 
> thanks for the information.
> 
> btw, do you see anything usefull in the log i attached to my other email ?
Well I found lots of unreleased stuff in the tuxkart code and I'm cleaning 
this up at the moment, but might need 1 or 2 days more.

Greetings,
	Matze

Re: [TuxKart-devel] Slowness - really related with Karts?

[James G. <j....@vi...>]

Does anyone know where to start looking for whatever the show-stopping
problem in the tuxkart cvs is right now?

It's pretty frustrating trying to find out what the problem is as each
time I run tuxkart I have to reboot my computer.

cvs -z3 history -a -e -D "8 days ago" gives:

U 2004-09-02 04:17 +0000 evilynux     1.1  Player.cxx        
tuxkart/src     == <remote>/src
U 2004-09-02 04:17 +0000 evilynux     1.1  Player.h          
tuxkart/src     == <remote>/src
M 2004-08-28 16:35 +0000 jamesgregory 1.4  gownsbow.track    
tuxkart/data    == <remote>
M 2004-08-28 16:35 +0000 jamesgregory 1.4  startrack.track   
tuxkart/data    == <remote>
M 2004-08-29 00:55 +0000 jamesgregory 1.5  ConfigControls.cxx
tuxkart/src/gui == <remote>
M 2004-08-29 00:55 +0000 jamesgregory 1.9  NumPlayers.cxx    
tuxkart/src/gui == <remote>
M 2004-08-29 00:55 +0000 jamesgregory 1.7  Options.cxx       
tuxkart/src/gui == <remote>
M 2004-08-29 00:55 +0000 jamesgregory 1.3  PlayerControls.cxx
tuxkart/src/gui == <remote>
U 2004-09-01 18:32 +0000 jamesgregory 1.1  Player.cxx        
tuxkart/src     == <remote>/src
U 2004-09-01 18:32 +0000 jamesgregory 1.1  Player.h          
tuxkart/src     == <remote>/src
U 2004-09-05 13:42 +0000 jamesgregory 1.10 StartScreen.cxx   
tuxkart/src     == <remote>
U 2004-09-05 13:45 +0000 jamesgregory 1.35 sdldrv.cxx        
tuxkart/src     == <remote>
G 2004-08-29 10:24 +0000 matzebraun   1.36 Driver.cxx        
tuxkart/src     == <remote>/src
U 2004-09-02 14:18 +0000 matzebraun   1.1  Player.cxx        
tuxkart/src     == <remote>/src
U 2004-09-02 14:18 +0000 matzebraun   1.1  Player.h          
tuxkart/src     == <remote>/src
G 2004-09-04 12:46 +0000 matzebraun   1.35 RaceGUI.cxx       
tuxkart/src/gui == <remote>/src/gui
O 2004-08-28 21:39 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
M 2004-08-28 22:05 +0000 oaf_thadres  1.5  Config.cxx        
tuxkart/src     == <remote>
M 2004-08-28 22:05 +0000 oaf_thadres  1.3  Config.h          
tuxkart/src     == <remote>
M 2004-08-28 22:05 +0000 oaf_thadres  1.47 KartDriver.cxx    
tuxkart/src     == <remote>
M 2004-08-28 22:22 +0000 oaf_thadres  1.7  sound.cxx         
tuxkart/src     == <remote>
M 2004-08-28 22:22 +0000 oaf_thadres  1.6  sound.h           
tuxkart/src     == <remote>
M 2004-08-28 22:41 +0000 oaf_thadres  1.77 start_tuxkart.cxx 
tuxkart/src     == <remote>
O 2004-08-29 17:38 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-08-29 19:41 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-08-29 19:49 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
M 2004-08-29 19:50 +0000 oaf_thadres  1.6  Config.cxx        
tuxkart/src     == <remote>
M 2004-08-29 19:50 +0000 oaf_thadres  1.4  Config.h          
tuxkart/src     == <remote>
M 2004-08-29 19:50 +0000 oaf_thadres  1.39 Makefile.am       
tuxkart/src     == <remote>
M 2004-08-29 19:50 +0000 oaf_thadres  1.35 sdldrv.cxx        
tuxkart/src     == <remote>
M 2004-08-29 19:50 +0000 oaf_thadres  1.12 sdldrv.h          
tuxkart/src     == <remote>
M 2004-08-29 19:50 +0000 oaf_thadres  1.4  PlayerControls.cxx
tuxkart/src/gui == <remote>
M 2004-08-29 19:50 +0000 oaf_thadres  1.3  PlayerControls.h  
tuxkart/src/gui == <remote>
O 2004-08-30 03:02 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-09-01 02:17 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
M 2004-09-01 02:21 +0000 oaf_thadres  1.7  Config.cxx        
tuxkart/src     == <remote>
A 2004-09-01 02:21 +0000 oaf_thadres  1.1  Player.cxx        
tuxkart/src     == <remote>
A 2004-09-01 02:21 +0000 oaf_thadres  1.1  Player.h          
tuxkart/src     == <remote>
O 2004-09-01 14:17 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-09-02 04:19 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-09-02 22:00 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-09-03 13:24 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-09-05 02:44 +0000 oaf_thadres  tuxkart         =tuxkart=
<remote>/*
O 2004-08-29 16:25 +0000 rmcruz       tuxkart         =tuxkart=
<remote>/*
M 2004-08-29 17:24 +0000 rmcruz       1.30 RaceGUI.cxx       
tuxkart/src/gui == <remote>
M 2004-08-29 17:24 +0000 rmcruz       1.8  RaceGUI.h         
tuxkart/src/gui == <remote>
O 2004-08-30 20:59 +0000 rmcruz       tuxkart         =tuxkart=
<remote>/*
O 2004-08-31 17:45 +0000 rmcruz       tuxkart         =tuxkart=
<remote>/*
O 2004-09-01 11:43 +0000 rmcruz       tuxkart         =tuxkart=
<remote>/*
O 2004-09-01 11:56 +0000 rmcruz       tuxkart         =tuxkart=
<remote>/*
M 2004-09-01 15:22 +0000 rmcruz       1.31 RaceGUI.cxx       
tuxkart/src/gui == <remote>
M 2004-09-01 15:22 +0000 rmcruz       1.9  RaceGUI.h         
tuxkart/src/gui == <remote>
M 2004-09-01 21:45 +0000 rmcruz       1.32 RaceGUI.cxx       
tuxkart/src/gui == <remote>
M 2004-09-01 21:45 +0000 rmcruz       1.10 RaceGUI.h         
tuxkart/src/gui == <remote>
M 2004-09-01 22:15 +0000 rmcruz       1.33 RaceGUI.cxx       
tuxkart/src/gui == <remote>
M 2004-09-01 22:15 +0000 rmcruz       1.11 RaceGUI.h         
tuxkart/src/gui == <remote>
M 2004-09-02 13:48 +0000 rmcruz       1.34 RaceGUI.cxx       
tuxkart/src/gui == <remote>
M 2004-09-02 13:48 +0000 rmcruz       1.12 RaceGUI.h         
tuxkart/src/gui == <remote>
O 2004-09-03 11:11 +0000 rmcruz       tuxkart         =tuxkart=
<remote>/*
M 2004-09-04 11:17 +0000 rmcruz       1.35 RaceGUI.cxx       
tuxkart/src/gui == <remote>
M 2004-09-04 11:17 +0000 rmcruz       1.13 RaceGUI.h         
tuxkart/src/gui == <remote>
O 2004-09-04 14:34 +0000 rmcruz       tuxkart         =tuxkart=
<remote>/*

At what point did it stop working?
To summarise the above, the people who have edited tuxkart most
recently, most recent edit last, are:

evilynux
jamesgregory
maztebraun
oaf_thadres
rmcruz

	James

Re: [TuxKart-devel] Valgrind: hunting possible leaks

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

On Sat, 4 Sep 2004 14:45:17 +0200 (CEST), Matze Braun wrote
> valgrind has problems with some hacks the nvidia and ati opengl 
> drivers are doing. An "export __GL_FORCE_GENERIC_CPU=1" helps for 
> nvidia cards, for ati you can only try to link tuxkart with mesa 
> instead of ati opengl.

I've an nVidia, i've just tried __GL_FORCE_GENERIC_CPU=1, but i don't see any
difference. They're still alot of false positives in
/usr/lib/tls/libGL.so.1.0.5336.


> > I'll try kcachegrind to see if i can get to understand more.
> cachegrind is for testing the performance of an App when you 
> consider cpu caches so that you can optimize your code to better fit 
> inside the data and command-caches of the cpu. That's only usefull 
> if you need to tweak the last 5% performance of your app, we're not 
> at that point in tuxkart yet.

thanks for the information.

btw, do you see anything usefull in the log i attached to my other email ?

-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] Valgrind: hunting possible leaks

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

valgrind has problems with some hacks the nvidia and ati opengl drivers 
are doing.
An "export __GL_FORCE_GENERIC_CPU=1" helps for nvidia cards, for ati you 
can only try to link tuxkart with mesa instead of ati opengl.

On Fri, 3 Sep 2004, Pascal Giard wrote:

> With valgrind 2.2, i used the following:
> 
> valgrind --tool=memcheck --leak-check=yes ./tuxkart 2> /tmp/leaks.log
> 
> the first thing i notice is that the following apears very frequently (27
> times just by making my way thru until i reach the track selection screen)
> along the way:
> 
> ==1520== Syscall param ioctl(generic) contains uninitialised or unaddressable
> byte(s)
> ==1520==    at 0x4334AA54: ioctl (in /lib/tls/libc-2.3.2.so)
> ==1520==    by 0x4497DA91: (within /usr/lib/tls/libGL.so.1.0.5336)
> ==1520==  Address 0x52BFE3B0 is on thread 1's stack
> 
> 
> Some other interesting parts:
> -----------------------------
> 
> ==1520== Use of uninitialised value of size 2
> ==1520==    at 0x4EED76EA: slSample::changeRate(int) (in
> /usr/lib/libplibsl.so.1.8.3)
> ==1520==    by 0x4EED7366: slSample::autoMatch(slDSP const*) (in
> /usr/lib/libplibsl.so.1.8.3)
> ==1520==    by 0x8070AD9: SoundSystem::SoundSystem() (sl.h:240)
> ==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)
> 
> ==1520== Conditional jump or move depends on uninitialised value(s)
> ==1520==    at 0x1B904A38: strcmp (mac_replace_strmem.c:251)
> ==1520==    by 0x80702D1: SoundSystem::change_track(char const*) (sound.cxx:57)
> ==1520==    by 0x8070B18: SoundSystem::SoundSystem() (sound.cxx:113)
> ==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)
These are bugs in plib where uninitialized variables are accessed, I've 
seen them too but didn't find the time yet to investigate as they don't 
seem to harm in most cases...

> 
> 
> Another one that appears frequently:
> ------------------------------------
> 
> ==1520== Use of uninitialised value of size 4
> ==1520==    at 0x4EEF6E0F: sgBox::extend(float const*) (in
> /usr/lib/libplibsg.so.1.8.3)
> ==1520==    by 0x4F021436: ssgVtxTable::recalcBSphere() (in
> /usr/lib/libplibssg.so.1.8.3)
> ==1520==    by 0x4F02030C: ssgVtxTable::ssgVtxTable(unsigned, ssgVertexArray*,
> ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) (in
> /usr/lib/libplibssg.so.1.8.3)
> ==1520==    by 0x80798F5: ParticleSystem::ParticleSystem(int, int, float, int,
> float, float) (ssg.h:159)
> 
> I'll stop here for now...
> 
> To say the least, i don't really understand how i should react to those
> informations... 
> Almost all entries mention my /usr/lib/tls/libGL.so.1.0.5336, but if it gets
> called the wrong way, it's just plain normal.
> 
> I'll try kcachegrind to see if i can get to understand more.
cachegrind is for testing the performance of an App when you consider cpu 
caches so that you can optimize your code to better fit inside the data 
and command-caches of the cpu. That's only usefull if you need to tweak 
the last 5% performance of your app, we're not at that point in tuxkart 
yet.

Greetings,
	Matze

[TuxKart-devel] Valgrind: more informations

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

I reran valgrind, but i "played" ~20secs.

Attached to this mail, you'll find the comnplete log.

Here's the summary:
==3134== LEAK SUMMARY:
==3134==    definitely lost: 186887 bytes in 621 blocks.
==3134==    possibly lost:   15640 bytes in 9 blocks.
==3134==    still reachable: 4863302 bytes in 86441 blocks.
==3134==         suppressed: 200 bytes in 1 blocks.
==3134== Reachable blocks (those to which a pointer was found) are not shown.
==3134== To see them, rerun with: --show-reachable=yes

Based on that (i don't know how reliable it is) either there isn't much memory
leaks (a sum of 185kb in 621 blocks isn't much) or "definitely lost: 186887
bytes in 621 blocks" means that 186887 bytes is lost 621 times, meaning ~111
Mb and we've an explanation.

Most leaks are in either /usr/lib/libplibssg.so.1.8.3 or KartDriver.cxx.

I hope this helps (and that someone will be able to interpret that information),

-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] Valgrind: hunting possible leaks

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

With valgrind 2.2, i used the following:

valgrind --tool=memcheck --leak-check=yes ./tuxkart 2> /tmp/leaks.log

the first thing i notice is that the following apears very frequently (27
times just by making my way thru until i reach the track selection screen)
along the way:

==1520== Syscall param ioctl(generic) contains uninitialised or unaddressable
byte(s)
==1520==    at 0x4334AA54: ioctl (in /lib/tls/libc-2.3.2.so)
==1520==    by 0x4497DA91: (within /usr/lib/tls/libGL.so.1.0.5336)
==1520==  Address 0x52BFE3B0 is on thread 1's stack


Some other interesting parts:
-----------------------------

==1520== Use of uninitialised value of size 2
==1520==    at 0x4EED76EA: slSample::changeRate(int) (in
/usr/lib/libplibsl.so.1.8.3)
==1520==    by 0x4EED7366: slSample::autoMatch(slDSP const*) (in
/usr/lib/libplibsl.so.1.8.3)
==1520==    by 0x8070AD9: SoundSystem::SoundSystem() (sl.h:240)
==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)

==1520== Conditional jump or move depends on uninitialised value(s)
==1520==    at 0x1B904A38: strcmp (mac_replace_strmem.c:251)
==1520==    by 0x80702D1: SoundSystem::change_track(char const*) (sound.cxx:57)
==1520==    by 0x8070B18: SoundSystem::SoundSystem() (sound.cxx:113)
==1520==    by 0x8070F71: initTuxKart(int, int, int) (start_tuxkart.cxx:87)


Another one that appears frequently:
------------------------------------

==1520== Use of uninitialised value of size 4
==1520==    at 0x4EEF6E0F: sgBox::extend(float const*) (in
/usr/lib/libplibsg.so.1.8.3)
==1520==    by 0x4F021436: ssgVtxTable::recalcBSphere() (in
/usr/lib/libplibssg.so.1.8.3)
==1520==    by 0x4F02030C: ssgVtxTable::ssgVtxTable(unsigned, ssgVertexArray*,
ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*) (in
/usr/lib/libplibssg.so.1.8.3)
==1520==    by 0x80798F5: ParticleSystem::ParticleSystem(int, int, float, int,
float, float) (ssg.h:159)

I'll stop here for now...

To say the least, i don't really understand how i should react to those
informations... 
Almost all entries mention my /usr/lib/tls/libGL.so.1.0.5336, but if it gets
called the wrong way, it's just plain normal.

I'll try kcachegrind to see if i can get to understand more.

-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] Blocking servers from black list

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

 Well, this list seems to be the only one with such problems.
 Anyway, since there is no option for mailing lists admin, I'll contact my 
ISP, as Steve suggested.

Cheers,
 Ricardo

Em Sexta, 3 de Setembro de 2004 13:31, o Frank Gevaerts escreveu:
> On Fri, Sep 03, 2004 at 01:16:43PM +0100, ri...@ae... wrote:
> > Hi there,
> >
> >  It looks like that this particular mailing list (cvs one works
> > fine) is blocking my mails, forcing me to send them using the
> > webmail interface, cause the SMTP server I use is listed on the
> > SpamCop's blacklist:
> > http://www.spamcop.net/w3m?action=checkblock&ip=195.23.133.212
> >
> >  Do you really feel this is necessary?
> >  I'm sure I ain't the only one having this problem, since, some time
> > ago, the all SMTP Spain servers were listed on that black list.
>
> I don't think anyone here can do anything about it. I think this is a
> global sourceforge thing.
>
> Frank
>
> > Cheers,
> >  Ricardo

-- 
Finagle's Eighth Law:
	If an experiment works, something has gone wrong.

Finagle's Ninth Law:
	No matter what results are expected, someone is always willing to
	fake it.

Finagle's Tenth Law:
	No matter what the result someone is always eager to misinterpret it.

Finagle's Eleventh Law:
	No matter what occurs, someone believes it happened according to
	his pet theory.

Re: [TuxKart-devel] Blocking servers from black list

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

Frank Gevaerts wrote:
> On Fri, Sep 03, 2004 at 01:16:43PM +0100, ri...@ae... wrote:
> 
>>Hi there, 
>> 
>> It looks like that this particular mailing list (cvs one works 
>>fine) is blocking my mails, forcing me to send them using the 
>>webmail interface, cause the SMTP server I use is listed on the 
>>SpamCop's blacklist: 
>>http://www.spamcop.net/w3m?action=checkblock&ip=195.23.133.212 
>> 
>> Do you really feel this is necessary? 
>> I'm sure I ain't the only one having this problem, since, some time 
>>ago, the all SMTP Spain servers were listed on that black list. 
> 
> 
> I don't think anyone here can do anything about it. I think this is a
> global sourceforge thing.

Yeah - that's true.  There is nothing under the mail-admin page to do
with blacklisting.

Rick should probably get his ISP to talk to SourceForge about it.

---------------------------- 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] tuxkart cvs being slow...

[James G. <j....@vi...>]

On Fri, 2004-09-03 at 13:45, Christoph Brill wrote:
> I worked several times with valgrind. And I storngly recommend to use 
> version 2.1 and above. 2.2 should work on ppc architecture, but that's 
> experimental. 2.0 is SLOW! And I mean it!
> Working with valgrind is really easy, simply run:
> 
> valgrind --tool=memcheck --leak-check=yes ./tuxkart
> 
> and look at the output (if it's much output, you can tell valgrind to 
> use a logfile, but I don't know the option right now)

Putting 2> valgrind.log on the end of the above works.

However, I think valgrind is best left to people with a faster PC than
mine (800MHz).

	James

Re: [TuxKart-devel] Blocking servers from black list

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

ri...@ae... writes:

>  Do you really feel this is necessary? 

Its a global sourceforge thing, doesn't have anything todo with this
particular mailinglist.

>  I'm sure I ain't the only one having this problem, since, some time 
> ago, the all SMTP Spain servers were listed on that black list. 

Its something your provider needs to fix, spamcop is just blocking
sites which have send spam, if your provider stops sending spam,
spamcop will stop blocking it so complain to your provider or switch
to another provider.

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

Re: [TuxKart-devel] tuxkart cvs being slow...

[Christoph B. <chr...@gm...>]

I worked several times with valgrind. And I storngly recommend to use=20
version 2.1 and above. 2.2 should work on ppc architecture, but that's=20
experimental. 2.0 is SLOW! And I mean it!
Working with valgrind is really easy, simply run:

valgrind --tool=3Dmemcheck --leak-check=3Dyes ./tuxkart

and look at the output (if it's much output, you can tell valgrind to=20
use a logfile, but I don't know the option right now)

ri...@ae... wrote:

> That would explain why after a while it gets so, so, so damn slow=20
>that I have =20
>no choice, but to reboot the system.=20
>=20
> There's a KDE utility called Valgrind that can detect memory=20
>allocation bugs. =20
>I dunno how it works, but it might be a good idea for a programmer=20
>to use it.=20
> Valgrind's webpage: http://valgrind.kde.org/=20
>=20
>Cheers,=20
> Ricardo=20
>=20
>Em Sexta, 3 de Setembro de 2004 10:45, o Steve Baker escreveu:=20
> =20
>
>>Pascal Giard wrote:=20
>>   =20
>>
>>>after playing for ~25secs:=20
>>>
>>>Active:         227192 kB=20
>>>Inactive:           52 kB=20
>>>
>>>More infos: I played a quick race in "race track" using penny in=20
>>>     =20
>>>
>320x240=20
> =20
>
>>>window mode. It started lagging very fast, after ~16secs.=20
>>>     =20
>>>
>>No wonder it's going slow after a while - it's swapping!=20
>>
>>   =20
>>
>-- =20
>There's small choice in rotten apples.=20
>                -- William Shakespeare, "The Taming of the Shrew"=20
>_________________________________________________________
>Revista S=E1bado - 12 edi=E7=F5es por um euro - Sem Compromisso=20
>clique aqui: http://revistasabado.online.pt
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dclick
>_______________________________________________
>Tuxkart-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
>
> =20
>

Re: [TuxKart-devel] Blocking servers from black list

[Frank G. <fr...@ge...>]

On Fri, Sep 03, 2004 at 01:16:43PM +0100, ri...@ae... wrote:
> Hi there, 
>  
>  It looks like that this particular mailing list (cvs one works 
> fine) is blocking my mails, forcing me to send them using the 
> webmail interface, cause the SMTP server I use is listed on the 
> SpamCop's blacklist: 
> http://www.spamcop.net/w3m?action=checkblock&ip=195.23.133.212 
>  
>  Do you really feel this is necessary? 
>  I'm sure I ain't the only one having this problem, since, some time 
> ago, the all SMTP Spain servers were listed on that black list. 

I don't think anyone here can do anything about it. I think this is a
global sourceforge thing.

Frank

>  
> Cheers, 
>  Ricardo 

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

[TuxKart-devel] Blocking servers from black list

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

Hi there,=20
=20
 It looks like that this particular mailing list (cvs one works=20
fine) is blocking my mails, forcing me to send them using the=20
webmail interface, cause the SMTP server I use is listed on the=20
SpamCop's blacklist:=20
http://www.spamcop.net/w3m?action=3Dcheckblock&ip=3D195.23.133.212=20
=20
 Do you really feel this is necessary?=20
 I'm sure I ain't the only one having this problem, since, some time=20
ago, the all SMTP Spain servers were listed on that black list.=20
=20
Cheers,=20
 Ricardo=20
_________________________________________________________
Revista S=E1bado - 12 edi=E7=F5es por um euro - Sem Compromisso=20
clique aqui: http://revistasabado.online.pt

Re: [TuxKart-devel] tuxkart cvs being slow...

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

 That would explain why after a while it gets so, so, so damn slow=20
that I have =20
no choice, but to reboot the system.=20
=20
 There's a KDE utility called Valgrind that can detect memory=20
allocation bugs. =20
I dunno how it works, but it might be a good idea for a programmer=20
to use it.=20
 Valgrind's webpage: http://valgrind.kde.org/=20
=20
Cheers,=20
 Ricardo=20
=20
Em Sexta, 3 de Setembro de 2004 10:45, o Steve Baker escreveu:=20
> Pascal Giard wrote:=20
> > after playing for ~25secs:=20
> >=20
> > Active:         227192 kB=20
> > Inactive:           52 kB=20
> >=20
> > More infos: I played a quick race in "race track" using penny in=20
320x240=20
> > window mode. It started lagging very fast, after ~16secs.=20
>=20
> No wonder it's going slow after a while - it's swapping!=20
>=20
-- =20
There's small choice in rotten apples.=20
                -- William Shakespeare, "The Taming of the Shrew"=20
_________________________________________________________
Revista S=E1bado - 12 edi=E7=F5es por um euro - Sem Compromisso=20
clique aqui: http://revistasabado.online.pt

Re: [TuxKart-devel] tuxkart cvs being slow...

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

Pascal Giard wrote:

> after playing for ~25secs:

> Active:         227192 kB
> Inactive:           52 kB
> 
> More infos: I played a quick race in "race track" using penny in 320x240
> window mode. It started lagging very fast, after ~16secs.

No wonder it's going slow after a while - it's swapping!

---------------------------- 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] tuxkart cvs being slow...

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

Well... it seems like there are memory leaks.

before starting tuxkart:

evilynux@LinOpen:~/CVS/tuxkart$ cat /proc/meminfo
MemTotal:       256004 kB
MemFree:        119936 kB
Buffers:          1504 kB
Cached:          35352 kB
SwapCached:      45688 kB
Active:          92204 kB
Inactive:        24868 kB
[...]


after playing for ~25secs:

evilynux@LinOpen:~/CVS/tuxkart$ cat /proc/meminfo
MemTotal:       256004 kB
MemFree:          2012 kB
Buffers:           664 kB
Cached:          10268 kB
SwapCached:      40940 kB
Active:         227192 kB
Inactive:           52 kB


More infos: I played a quick race in "race track" using penny in 320x240
window mode. It started lagging very fast, after ~16secs.

-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] Slowness - really related with Karts?

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

F12 enables FPS display in the cvs version.

Greetings,
	Matze

On Thu, 2 Sep 2004, Ricardo Cruz wrote:

> Em Quinta, 2 de Setembro de 2004 00:00, o Ingo Ruhnke escreveu:
> > ri...@ae... writes:
> > >  The game is quite slow and, after a while, it can get the system
> > > unusable. I don't know what the problem is, but it looks like
> > > polygons have been reduced from Karts. My question is if that is
> > > really needed?
> >
> > In short, yes. Simple test, look at fps with karts in view and look at
> > fps with karts out of the view so that they can get culled away. The
> > fps easily double or tripple without the karts in the view. There
> > might however be other reasons for the slowness, but the karts for
> > sure are one of them.
> >
> > > This Karts polygons reduction is resulting in Karts uglier and less
> > > detailed than the DOS Kart games ones.
> >
> > Textures will help a quite a bit to bring some details back, some
> > proper LOD should also help, especially with the wheels which really
> > tend to look sucky with the lower poly models.
> 
>  In my system, there is no significant change on speed when Karts are there or 
> not. I have FPS disabled (how can one enable them?), but I can't really tell 
> the difference. Of course, in other video cards - especially the badly X11 
> supported, like ATI - there might be significant lag when a few karts are 
> visible.
>  But the slowness that occurs after a while (I don't even have to drive, just 
> to stay there) is surely the responsible of some bad code.
> 
>  Anyway, maybe the best solution would be to have a Karts detail option in 
> Graphics Options, and one could change between both versions of the cards: 
> the one with lots of polygons and the other with fewer.
> 
>  It is also good to know that textures can help - haven't remember of those -, 
> but ugly stuff like those heads made of squares will not be helped:
> http://rpmcruz.planetaclix.pt/trash/tuxkart-dinoface.png
> 
> Cheers,
>  Ricardo
> 
> -- 
> 	A novice asked the master: "I have a program that sometimes runs and
> sometimes aborts.  I have followed the rules of programming, yet I am totally
> baffled. What is the reason for this?"
> 	The master replied: "You are confused because you do not understand
> the Tao.  Only a fool expects rational behavior from his fellow humans.  Why
> do you expect it from a machine that humans have constructed?  Computers
> simulate determinism; only the Tao is perfect.
> 	The rules of programming are transitory; only the Tao is eternal.
> Therefore you must contemplate the Tao before you receive enlightenment."
> 	"But how will I know when I have received enlightenment?" asked the
> novice.
> 	"Your program will then run correctly," replied the master.
> 		-- Geoffrey James, "The Tao of Programming"
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
> 
> 

Re: [TuxKart-devel] Alpha not working nicely on RaceGUI.cxx

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

 Yes, I have. Doesn't work either. :P
 Maybe it is just that blending is disabled somewhere... I'll have a look at 
this.

Cheers,
 Ricardo

Em Quarta, 1 de Setembro de 2004 23:40, o Charles Goodwin escreveu:
> On Wed, 2004-09-01 at 23:29 +0100, ri...@ae... wrote:
> >  I don't know OpenGL that well, but shouldn't this be something like
> > this:
> >
> > glEnable(GL_BLEND);
> > glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
>
> Have you tried it?
>
> (Sorry, I don't know either.)
-- 
Whom the gods would destroy, they first teach BASIC.

Re: [TuxKart-devel] Slowness - really related with Karts?

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

Em Quinta, 2 de Setembro de 2004 00:00, o Ingo Ruhnke escreveu:
> ri...@ae... writes:
> >  The game is quite slow and, after a while, it can get the system
> > unusable. I don't know what the problem is, but it looks like
> > polygons have been reduced from Karts. My question is if that is
> > really needed?
>
> In short, yes. Simple test, look at fps with karts in view and look at
> fps with karts out of the view so that they can get culled away. The
> fps easily double or tripple without the karts in the view. There
> might however be other reasons for the slowness, but the karts for
> sure are one of them.
>
> > This Karts polygons reduction is resulting in Karts uglier and less
> > detailed than the DOS Kart games ones.
>
> Textures will help a quite a bit to bring some details back, some
> proper LOD should also help, especially with the wheels which really
> tend to look sucky with the lower poly models.

 In my system, there is no significant change on speed when Karts are there or 
not. I have FPS disabled (how can one enable them?), but I can't really tell 
the difference. Of course, in other video cards - especially the badly X11 
supported, like ATI - there might be significant lag when a few karts are 
visible.
 But the slowness that occurs after a while (I don't even have to drive, just 
to stay there) is surely the responsible of some bad code.

 Anyway, maybe the best solution would be to have a Karts detail option in 
Graphics Options, and one could change between both versions of the cards: 
the one with lots of polygons and the other with fewer.

 It is also good to know that textures can help - haven't remember of those -, 
but ugly stuff like those heads made of squares will not be helped:
http://rpmcruz.planetaclix.pt/trash/tuxkart-dinoface.png

Cheers,
 Ricardo

-- 
	A novice asked the master: "I have a program that sometimes runs and
sometimes aborts.  I have followed the rules of programming, yet I am totally
baffled. What is the reason for this?"
	The master replied: "You are confused because you do not understand
the Tao.  Only a fool expects rational behavior from his fellow humans.  Why
do you expect it from a machine that humans have constructed?  Computers
simulate determinism; only the Tao is perfect.
	The rules of programming are transitory; only the Tao is eternal.
Therefore you must contemplate the Tao before you receive enlightenment."
	"But how will I know when I have received enlightenment?" asked the
novice.
	"Your program will then run correctly," replied the master.
		-- Geoffrey James, "The Tao of Programming"

Re: [TuxKart-devel] Slowness - really related with Karts?

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

ri...@ae... writes:

>  The game is quite slow and, after a while, it can get the system
> unusable. I don't know what the problem is, but it looks like
> polygons have been reduced from Karts. My question is if that is
> really needed?

In short, yes. Simple test, look at fps with karts in view and look at
fps with karts out of the view so that they can get culled away. The
fps easily double or tripple without the karts in the view. There
might however be other reasons for the slowness, but the karts for
sure are one of them.

> This Karts polygons reduction is resulting in Karts uglier and less
> detailed than the DOS Kart games ones.

Textures will help a quite a bit to bring some details back, some
proper LOD should also help, especially with the wheels which really
tend to look sucky with the lower poly models.

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