Thread: [TuxKart-devel] Slowness - really related with Karts?
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel
|
From: <ri...@ae...> - 2004-09-01 22:28:30
|
Hello there,=20
=20
The game is quite slow and, after a while, it can get the system=20
unusable. I =20
don't know what the problem is, but it looks like polygons have been=20
reduced =20
from Karts.=20
My question is if that is really needed? It doesn't look like Karts=20
are the =20
problem, since it is slow as well when the Karts are not there, and=20
the game =20
keep getting slow is not certainly fault of the Karts.=20
This Karts polygons reduction is resulting in Karts uglier and less=20
detailed =20
than the DOS Kart games ones.=20
=20
By the way, I'm using a Nvidia GeForce 4 MX 440. I believe with the=20
latest =20
(or so) version of the nvidia provided drivers.=20
=20
Cheers,=20
Ricardo=20
-- =20
The net of law is spread so wide,=20
No sinner from its sweep may hide.=20
Its meshes are so fine and strong,=20
They take in every child of wrong.=20
O wondrous web of mystery!=20
Big fish alone escape from thee!=20
-- James Jeffrey Roche=20
_________________________________________________________
Pensa comprar um carro novo? Pe=E7a uma proposta online: Audi, VW ou Skod=
a
http://www.aeiou.pt/promo/siva/
|
|
From: Charles G. <ch...@ve...> - 2004-09-01 22:47:28
|
On Wed, 2004-09-01 at 23:28 +0100, ri...@ae... wrote: > 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? It doesn't look like > Karts are the problem, since it is slow as well when the Karts > are not there, and the game keep getting slow is not certainly > fault of the Karts. Consensus is that the problem lies with the way PLIB handles the tracks (ie large polygonal models) and the physics code taking up far too much CPU time. Whilst people have been poking around the physics code, it seems nobody has actually seen nor solved that particular issue. There are patches for PLIB that improve things roughly twofold, and hopefully they will make it into PLIB sooner rather than later. But even then, the performance is no where near what it should be for such a relatively simple game. The only other way to improve things on this issue is to break up the tracks into sections, but that's messing the level designers about. Really, Steve needs to grab PLIB by the scruff of the neck on this issue and other PLIB problems, but he's publicly refusing to get involved. (Which is surprising, because if he'd fixed them, then there would be no need for the current SDL dependency and he'd be happy again. *Sigh*) -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Ingo R. <gr...@gm...> - 2004-09-01 23:00:34
|
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 |
|
From: Ricardo C. <ri...@ae...> - 2004-09-02 09:09:05
|
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" |
|
From: Matze B. <ma...@br...> - 2004-09-02 14:20:19
|
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 > > |
|
From: Ingo R. <gr...@gm...> - 2004-09-05 22:52:16
|
Ricardo Cruz <ri...@ae...> writes: > 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 Thats just ugly because smooth shading is missing, with the flat shading it looks of course rather blocky. Anyway, polygon count really doesn't matter all that much, just look at a doom3 model: http://static.hugi.is/games/doom3/screens/doom3page3.jpg They are extremly edgy too, but due to some kickass bump-mapping and shading that doesn't really matter at all. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: James G. <j....@vi...> - 2004-09-05 15:36:26
|
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 |
|
From: Ricardo C. <ri...@ae...> - 2004-09-05 20:35:55
|
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. |
|
From: James G. <j....@vi...> - 2004-09-05 16:12:47
|
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 |
|
From: James G. <j....@vi...> - 2004-09-05 16:20:54
|
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 |
|
From: Ricardo C. <ri...@ae...> - 2004-09-05 20:51:14
|
> 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. |
|
From: James G. <j....@vi...> - 2004-09-05 21:05:05
|
On Sun, 2004-09-05 at 22:00, Ricardo Cruz wrote:
> 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.
It is possible to cache text textures. For numbers you have to do it in
parts - rather than having "9", "99" and "999", you just cache textures
for the numbers 0-9 for each font you want to draw numbers with, and
then put the textures together to create numbers, timers, etc. You also
need an individual texture for a colon (":") and "mph".
You then have textures for "Wrong Way!", "Ready!", "Set!", "Go!",
"Congratulations!", "1st", "2nd", "3rd", etc, etc.
I've started work but it's very boring.
James
|
|
From: Steve B. <sjb...@ai...> - 2004-09-06 01:03:31
|
James Gregory wrote: > Because you've brought it up again, I'll put the case forward again. No > dependencies are better than dependencies, sure. But given the choice > between a crap GUI and no fullscreen mode, or a nice GUI and fullscreen > mode but with dependencies, or a nice GUI and fullscreen mode and no > dependencies but a couple of months of extra coding, which is best? There is NO indication that you can't have a decent GUI with the PUI toolkit that TuxKart was originally using. I explained that fullscreen mode should be obtainable with PW - but if it couldn't we could modify it to do so (since I also run the PLIB project - this should be easy). I wasn't enthusiastic about expanding the scope of the GOTM effort to encompass a drastically re-engineered GUI - and I think (given the extension of the project beyond the originally estimated 2 months) that I was correct. However, *had* I been interested in doing that, PUI could have done the job perfectly well without introducing more dependancies. > As I said already, the use of ttf for in game text was a matter of what > was easiest, not what is best. What would have been easiest would have been to use PLIB's font library and not getting into having to cache fonts and all that nonsense. ---------------------------- 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----- |
|
From: James G. <j....@vi...> - 2004-09-06 01:40:53
|
On Mon, 2004-09-06 at 02:02, Steve Baker wrote: > James Gregory wrote: > > > Because you've brought it up again, I'll put the case forward again. No > > dependencies are better than dependencies, sure. But given the choice > > between a crap GUI and no fullscreen mode, or a nice GUI and fullscreen > > mode but with dependencies, or a nice GUI and fullscreen mode and no > > dependencies but a couple of months of extra coding, which is best? > > There is NO indication that you can't have a decent GUI with the PUI toolkit > that TuxKart was originally using. It depends if by "decent" you mean "functional" or "looks like a computer game rather than a multi-coloured office application". > I explained that fullscreen mode should > be obtainable with PW - but if it couldn't we could modify it to do so (since > I also run the PLIB project - this should be easy). You never seemed like you were going to do anything about it. When SDL was originally put in it was guarded by #ifdefs, giving you a chance to say "OK, I'll sort out fullscreen with pw if you remove SDL". Instead you just responded with a flame. Our response was to say "Well, if you're going to be like that" and give up on trying to find a middle ground. > > I wasn't enthusiastic about expanding the scope of the GOTM effort to encompass > a drastically re-engineered GUI - and I think (given the extension of the project > beyond the originally estimated 2 months) that I was correct. Most of the basic GUI code was converted from Neverball to TuxKart in one evening, with maybe another evening's worth of my time spent improving it further. Where myself or other people have used the gui to write e.g. character select screens, it has been no more effort than if these screens were built using plib. So the only person who has put any sizeable amount of time into rewriting the GUI of tuxkart when using plib could have freed their time for other things is me. However, as I have freely admitted on multiple occasions, I don't know very much about OpenGL, and so it's not like I would have fixed e.g. the falling-through-the-track bug instead. The main obstacle to a release in the immediate future remains the 3D engine, yet this isn't something I could have done anything about. You could have, but you decided you'd rather see GOTM fail (which isn't going to happen, but it is delaying it hugely and it is going to mean it won't be as good as it could have been). You are being totally irrational in arguing that the reason for this GOTM going on so long is because I spent a couple of evenings switching over from plib for the gui. The real thing behind all of this is that you wrote PLIB and you'd like to see as many games as possible based on it. You are outraged that a version of a game that you originally did most of the work for now uses rival libraries instead. I guess in a world where people are motivated by the credit they gain (i.e. OSS), this sort of thing isn't surprising (RMS does it plenty too), but I still think it's stupid. > However, *had* I > been interested in doing that, PUI could have done the job perfectly well without > introducing more dependancies. Again, your definition of "perfectly well" is not shared by everyone. > > > As I said already, the use of ttf for in game text was a matter of what > > was easiest, not what is best. > > What would have been easiest would have been to use PLIB's font library and not > getting into having to cache fonts and all that nonsense. James |
|
From: Matze B. <ma...@br...> - 2004-09-06 11:04:44
|
On Sun, 5 Sep 2004, Steve Baker wrote: > ... > > I wasn't enthusiastic about expanding the scope of the GOTM effort to encompass > a drastically re-engineered GUI - and I think (given the extension of the project > beyond the originally estimated 2 months) that I was correct. However, *had* I > been interested in doing that, PUI could have done the job perfectly well without > introducing more dependancies. Apart from all this other stupid stuff in this thread, here is the real problem! Steve: You didn't even accept the idea of changing the GUI. GoTM is not about getting some idiots who blindly implement your visions of a game, they have game-design ideas themselfes! Don't we have a right to discuss this a bit, since we planed to actually spend lots of our free time helping with the project? I'm really sad about the current state as I respect you as a great (opengl-) coder and the man who put LOTS of his time into plib and tuxkart. Greetings, Matze |
|
From: Ricardo C. <ri...@ae...> - 2004-09-05 21:40:15
|
Oh, creating a texture for every character... But why not just using a pixmap
format then (rather than the vectorial one - TTF)?
Ricardo
Em Domingo, 5 de Setembro de 2004 23:05, o James Gregory escreveu:
> On Sun, 2004-09-05 at 22:00, Ricardo Cruz wrote:
> > 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.
>
> It is possible to cache text textures. For numbers you have to do it in
> parts - rather than having "9", "99" and "999", you just cache textures
> for the numbers 0-9 for each font you want to draw numbers with, and
> then put the textures together to create numbers, timers, etc. You also
> need an individual texture for a colon (":") and "mph".
>
> You then have textures for "Wrong Way!", "Ready!", "Set!", "Go!",
> "Congratulations!", "1st", "2nd", "3rd", etc, etc.
>
> I've started work but it's very boring.
>
> James
>
--
My ritual differs slightly. What I do, first thing [in the morning], is I
hop into the shower stall. Then I hop right back out, because when I hopped
in I landed barefoot right on top of See Threepio, a little plastic robot
character from "Star Wars" whom my son, Robert, likes to pull the legs off
of while he showers. Then I hop right back into the stall because our dog,
Earnest, who has been alone in the basement all night building up powerful
dog emotions, has come bounding and quivering into the bathroom and wants
to greet me with 60 or 70 thousand playful nips, any one of which -- bear
in mind that I am naked and, without my contact lenses, essentially blind
-- could result in the kind of injury where you have to learn a whole new
part if you want to sing the "Messiah," if you get my drift. Then I hop
right back out, because Robert, with that uncanny sixth sense some children
have -- you cannot teach it; they either have it or they don't -- has chosen
exactly that moment to flush one of the toilets. Perhaps several of them.
-- Dave Barry
|
|
From: Steve B. <sjb...@ai...> - 2004-09-05 21:45:54
|
Ricardo Cruz wrote: > Oh, creating a texture for every character... Texture map switching would kill you. > But why not just using a pixmap > format then (rather than the vectorial one - TTF)? ...or you could put all the letters into one font texture... Oh - wait! That's how the game was originally written before everyone who thought they knew better came along! ---------------------------- 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----- |
|
From: James G. <j....@vi...> - 2004-09-05 22:00:14
|
On Sun, 2004-09-05 at 22:45, Steve Baker wrote: > Ricardo Cruz wrote: > > Oh, creating a texture for every character... > > Texture map switching would kill you. I must admit I don't actually know what that means. Though as I've already said I was only talking about individual textures for numbers, not letters, to begin with. As I said in more recent email it now looks as though I'm not even going to do that. > > But why not just using a pixmap > > format then (rather than the vectorial one - TTF)? > > ...or you could put all the letters into one font texture... > > Oh - wait! That's how the game was originally written before > everyone who thought they knew better came along! The general consensus, even if you don't agree, was that the old gui sucked and needed replacing. Rather than write a whole new GUI from scratch code was instead taken from Neverball, which was known to work well and meet our needs. The Neverball GUI uses SDL_ttf, which was never an issue in Neverball because it doesn't have much mid-game text, it mostly gets used just for menu screens. The in-game text in the old TuxKart was heavily pixellated and very ugly. Given that SDL_ttf was already being used for the menu screens, by far the easiest way to fix this problem by just switching the text drawing calls to use SDL_ttf, rather than using one thing for menu screens and another for in-game status text. Also, as much as you'd like this GOTM to end up not working due to dependency issues/SDL issues, it's not happening. The in game text can be sorted out in a couple of hours. By far the biggest problem continues to be the speed of the 3D engine. I don't know much about 3D engines, and so I don't want to blame anyone or anything in particular for this, but what I do know is that it's not the fault of SDL or SDL_ttf. James |
|
From: Ricardo C. <ri...@ae...> - 2004-09-06 11:21:33
|
Em Domingo, 5 de Setembro de 2004 22:45, o Steve Baker escreveu: > Ricardo Cruz wrote: > > Oh, creating a texture for every character... > > Texture map switching would kill you. > > > But why not just using a pixmap > > format then (rather than the vectorial one - TTF)? > > ...or you could put all the letters into one font texture... > That's what I meant about a pixmap image. > Oh - wait! That's how the game was originally written before > everyone who thought they knew better came along! > I was the one that implemented the TTF support. I don't really like games using TTF for various reasons from speed performance to ugliness to the fact that it's hard (or impossible) to add a missing(s) character(s). By the way, its funny that even console developers use pixmaps rather than vectorial graphics because they know how cpu expensive they can be, but most games still keep using TTF. But fact was that everybody seemed to agree that TTF usage was the way to go and someone would do it anyway. Since I've already done some work on the RaceGUI code, I stepped forward. Anyway, it is still time to revert this. If any pixmap (whataver the format Plib likes the most) is purposed, just send it to me and I'll revert things to use that. Cheers, Ricardo -- Q: What does friendship among Soviet nationalities mean? A: It means that the Armenians take the Russians by the hand; the Russians take the Ukrainians by the hand; the Ukranians take the Uzbeks by the hand; and they all go and beat up the Jews. |
|
From: Matze B. <ma...@br...> - 2004-09-06 13:28:17
|
Aehm did you actually take a look at what plibfnt does? Greetings, Matze On Mon, 6 Sep 2004, Ricardo Cruz wrote: > Em Domingo, 5 de Setembro de 2004 22:45, o Steve Baker escreveu: > > Ricardo Cruz wrote: > > > Oh, creating a texture for every character... > > > > Texture map switching would kill you. > > > > > But why not just using a pixmap > > > format then (rather than the vectorial one - TTF)? > > > > ...or you could put all the letters into one font texture... > > > That's what I meant about a pixmap image. > > > Oh - wait! That's how the game was originally written before > > everyone who thought they knew better came along! > > > > I was the one that implemented the TTF support. I don't really like games > using TTF for various reasons from speed performance to ugliness to the fact > that it's hard (or impossible) to add a missing(s) character(s). > By the way, its funny that even console developers use pixmaps rather than > vectorial graphics because they know how cpu expensive they can be, but most > games still keep using TTF. > > But fact was that everybody seemed to agree that TTF usage was the way to go > and someone would do it anyway. Since I've already done some work on the > RaceGUI code, I stepped forward. > Anyway, it is still time to revert this. If any pixmap (whataver the format > Plib likes the most) is purposed, just send it to me and I'll revert things > to use that. > > Cheers, > Ricardo > > -- > Q: What does friendship among Soviet nationalities mean? > A: It means that the Armenians take the Russians by the hand; the > Russians take the Ukrainians by the hand; the Ukranians take > the Uzbeks by the hand; and they all go and beat up the Jews. > > > ------------------------------------------------------- > 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 > > |
|
From: Ricardo C. <ri...@ae...> - 2004-09-06 14:50:59
|
Nope. Why? Does it support TTF fonts? The reason why I used SDL_ttf was because I was pointed to and there were already functions available to convert them into a texture. Cheers, Ricardo Em Segunda, 6 de Setembro de 2004 14:28, o Matze Braun escreveu: > Aehm did you actually take a look at what plibfnt does? > > Greetings, > Matze > > On Mon, 6 Sep 2004, Ricardo Cruz wrote: > > Em Domingo, 5 de Setembro de 2004 22:45, o Steve Baker escreveu: > > > Ricardo Cruz wrote: > > > > Oh, creating a texture for every character... > > > > > > Texture map switching would kill you. > > > > > > > But why not just using a pixmap > > > > format then (rather than the vectorial one - TTF)? > > > > > > ...or you could put all the letters into one font texture... > > > > That's what I meant about a pixmap image. > > > > > Oh - wait! That's how the game was originally written before > > > everyone who thought they knew better came along! > > > > I was the one that implemented the TTF support. I don't really like > > games using TTF for various reasons from speed performance to ugliness to > > the fact that it's hard (or impossible) to add a missing(s) character(s). > > By the way, its funny that even console developers use pixmaps rather > > than vectorial graphics because they know how cpu expensive they can be, > > but most games still keep using TTF. > > > > But fact was that everybody seemed to agree that TTF usage was the way > > to go and someone would do it anyway. Since I've already done some work > > on the RaceGUI code, I stepped forward. > > Anyway, it is still time to revert this. If any pixmap (whataver the > > format Plib likes the most) is purposed, just send it to me and I'll > > revert things to use that. > > > > Cheers, > > Ricardo > > -- What did Mickey Mouse get for Christmas? A Dan Quayle watch. -- heard from a Mike Dukakis field worker |
|
From: James G. <j....@vi...> - 2004-09-06 14:29:34
|
On Mon, 2004-09-06 at 12:31, Ricardo Cruz wrote: > But fact was that everybody seemed to agree that TTF usage was the way to go > and someone would do it anyway. Since I've already done some work on the > RaceGUI code, I stepped forward. > Anyway, it is still time to revert this. If any pixmap (whataver the format > Plib likes the most) is purposed, just send it to me and I'll revert things > to use that. > The general consensus seems to be that reverting to plib for the in game text would be a good idea, so yes, it would be good if you could do that. James |
|
From: Pascal G. <pa...@gu...> - 2004-09-06 17:31:52
|
As of current CVS version, the framerate as been greatly improved! On the beach and smoother than ever and impresses me... i guess not all tracks are broke into segments like that one ? i still wonder how come i get 2 to 4 fps in "little vulcano". the other hardly playable track is subsea with 10 to 20fps. -Pascal PS: am i the only one who often gets segfaults ? -- 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) |
|
From: James G. <j....@vi...> - 2004-09-05 21:48:26
|
On Sun, 2004-09-05 at 22:49, Ricardo Cruz wrote: > Oh, creating a texture for every character... But why not just using a pixmap > format then (rather than the vectorial one - TTF)? > I was only suggesting to create a texture for every number plus a colon, not every character. Still, this is a lot of hassle, and MazteB reckons that a more simple caching system that checks if a piece of text has changed since the last frame, and if it has simply re-renders the whole thing, would be good enough. James |
|
From: Jason T. R. <jt...@gt...> - 2004-09-05 22:24:07
|
Pardon me - I signed on early because the project seemed interesting, but the minute you guys blew off the originator, a guy whose name shows up at the end of 70% of the "OpenGL How To" searches on the Flightgear lists, the Gimp lists and the OpenGL forums, I knew I'd be wasting my time. So go ahead and flame him. The single font texture is THE definitive way it is done. Texture switching WILL kill you on an OpenGL or DirectX system. If you don't know what it means, Google for "Texture Switching" and I'll bet the experts point to some obscure 10 year old web page of Steve's. That is the reason that every commercial game you pick up has budgetted character textures into compact atlases and you never see a character, feature, deco or terrain piece jump across multiple textures. EVERY pro title uses a single texture font system to avoid it. ... and to answer your question, 2 full titles on N64 - a pure OpenGL box. Steve, Mail me when these guys go home. I code, model and do sound effects -- and hate sprawling dependency lists. JR James Gregory wrote: >On Sun, 2004-09-05 at 22:45, Steve Baker wrote: > > >>Ricardo Cruz wrote: >> >> >>> Oh, creating a texture for every character... >>> >>> >>Texture map switching would kill you. >> >> > >I must admit I don't actually know what that means. Though as I've >already said I was only talking about individual textures for numbers, >not letters, to begin with. As I said in more recent email it now looks >as though I'm not even going to do that. > > > >>>But why not just using a pixmap >>>format then (rather than the vectorial one - TTF)? >>> >>> >>...or you could put all the letters into one font texture... >> >>Oh - wait! That's how the game was originally written before >>everyone who thought they knew better came along! >> >> > >The general consensus, even if you don't agree, was that the old gui >sucked and needed replacing. Rather than write a whole new GUI from >scratch code was instead taken from Neverball, which was known to work >well and meet our needs. The Neverball GUI uses SDL_ttf, which was never >an issue in Neverball because it doesn't have much mid-game text, it >mostly gets used just for menu screens. > >The in-game text in the old TuxKart was heavily pixellated and very >ugly. Given that SDL_ttf was already being used for the menu screens, by >far the easiest way to fix this problem by just switching the text >drawing calls to use SDL_ttf, rather than using one thing for menu >screens and another for in-game status text. > >Also, as much as you'd like this GOTM to end up not working due to >dependency issues/SDL issues, it's not happening. The in game text can >be sorted out in a couple of hours. By far the biggest problem continues >to be the speed of the 3D engine. I don't know much about 3D engines, >and so I don't want to blame anyone or anything in particular for this, >but what I do know is that it's not the fault of SDL or SDL_ttf. > > 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 > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X