tuxkart-devel — TuxKart Developers.

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

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

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

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

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

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

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

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

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

Hi there,=20
=20
 Just wanna report that alpha isn't working that well in the=20
RaceGUI.cxx code. =20
I suspect it is because of this:=20
=20
  glEnable       ( GL_ALPHA_TEST ) ;=20
  glAlphaFunc    ( GL_GREATER, 0.1 ) ;=20
  glEnable       ( GL_BLEND      ) ;=20
=20
 I don't know OpenGL that well, but shouldn't this be something like=20
this:=20
=20
glEnable(GL_BLEND);=20
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);=20
=20
Cheers,=20
 Ricardo=20
=20
-- =20
To refuse praise is to seek praise twice.=20
=20
_________________________________________________________
Pensa comprar um carro novo? Pe=E7a uma proposta online: Audi, VW ou Skod=
a
http://www.aeiou.pt/promo/siva/

[TuxKart-devel] Cache for fonts

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

Hi there,=20
=20
 I've made fonts being cached to avoid calls to TTF_Open(). Anyone=20
knows if =20
this is really worth it?=20
=20
Cheers,=20
 Ricardo=20
=20
-- =20
How many retured bricklayers from FLORIDA are out purchasing PENCIL=20
SHARPENERS right NOW??=20
=20
_________________________________________________________
Pensa comprar um carro novo? Pe=E7a uma proposta online: Audi, VW ou Skod=
a
http://www.aeiou.pt/promo/siva/

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

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

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/

Re: [TuxKart-devel] Missing file on CVS

[r. m. <anj...@ya...>]

--- ri...@ae... wrote:

>  Looks like someone forgot to upload a file
> (Player.h) to CVS: 
>  

sorry about that,
i was busy with other things when making that commit,
and have been busy w/ university since
(i expect the same is true for quite a few others,
since IRC and the mailing-lists have been very quiet
the last so many days)

the Player class adds per player names (only used in
the control configuration gui currently), and the
saving and loading of the control configuration
(though i haven't sorted out the joystick use yet).
the only other problem w/ it is that the defaults are
currently loaded outside of the Config class, and they
are loaded AFTER the config file is loaded. so the
control is defaulted every time you start tuxkart. not
a hard thing to fix, but i've been busy (and no-one
else had the code).

hope it helps more than hurts,
-paul


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

[TuxKart-devel] Missing file on CVS

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

 Looks like someone forgot to upload a file (Player.h) to CVS:=20
=20
rick2@docelar:/home/prog/tuxkart/tuxkart/ > make=20
Making all in src=20
make[1]: Entering directory `/home/prog/tuxkart/tuxkart/src'=20
if g++ -DPACKAGE_NAME=3D\"\" -DPACKAGE_TARNAME=3D\"\"=20
-DPACKAGE_VERSION=3D\"\" =20
-DPACKAGE_STRING=3D\"\" -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"tuxkart\=
" =20
-DVERSION=3D\"0.4.0\" -DHAVE_LIBSDL=3D1 -DHAVE_LIBSDL_IMAGE=3D1=20
-DHAVE_LIBSDL_TTF=3D1 =20
-DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1 -DHAVE_SYS_STAT_H=3D1=20
-DHAVE_STDLIB_H=3D1 =20
-DHAVE_STRING_H=3D1 -DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1=20
-DHAVE_INTTYPES_H=3D1 =20
-DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_PTHREAD=3D1=20
-DSTDC_HEADERS=3D1 =20
-DLINUX_JOYSTICK_IS_PRESENT=3D1 =20
-DTUXKART_DATADIR=3D\"/usr/local/share/games/tuxkart\"  -I. -I.     -g=20
-O2 =20
-I/usr/include/SDL -D_REENTRANT -I/usr/X11R6/include  -Wall -MT=20
sdldrv.o -MD =20
-MP -MF ".deps/sdldrv.Tpo" \=20
  -c -o sdldrv.o `test -f 'sdldrv.cxx' || echo './'`sdldrv.cxx; \=20
then mv -f ".deps/sdldrv.Tpo" ".deps/sdldrv.Po"; \=20
else rm -f ".deps/sdldrv.Tpo"; exit 1; \=20
fi=20
In file included from sdldrv.cxx:33:=20
Config.h:26:20: Player.h: No such file or directory=20
In file included from sdldrv.cxx:33:=20
Config.h:47: error: syntax error before `[' token=20
sdldrv.cxx: In function `void setupControls()':=20
sdldrv.cxx:82: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:86: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:89: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:89: error: `CD_KEYBOARD' undeclared (first use this=20
function)=20
sdldrv.cxx:89: error: (Each undeclared identifier is reported only=20
once for =20
each function it appears in.)=20
sdldrv.cxx:89: error: `KC_LEFT' undeclared (first use this function)=20
sdldrv.cxx:90: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:90: error: `KC_RIGHT' undeclared (first use this=20
function)=20
sdldrv.cxx:91: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:91: error: `KC_UP' undeclared (first use this function)=20
sdldrv.cxx:92: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:92: error: `KC_DOWN' undeclared (first use this function)=20
sdldrv.cxx:93: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:93: error: `KC_WHEELIE' undeclared (first use this=20
function)=20
sdldrv.cxx:94: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:94: error: `KC_JUMP' undeclared (first use this function)=20
sdldrv.cxx:95: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:95: error: `KC_RESCUE' undeclared (first use this=20
function)=20
sdldrv.cxx:96: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:96: error: `KC_FIRE' undeclared (first use this function)=20
sdldrv.cxx:99: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:100: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:101: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:102: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:103: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:104: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:105: error: 'class Config' has no member named 'player'=20
sdldrv.cxx:106: error: 'class Config' has no member named 'player'=20
sdldrv.cxx: In function `void pollEvents()':=20
sdldrv.cxx:131: error: 'class Config' has no member named 'player'=20
sdldrv.cxx: In function `void kartInput(RaceSetup&)':=20
sdldrv.cxx:200: error: `Player' undeclared (first use this function)=20
sdldrv.cxx:200: error: `plyr' undeclared (first use this function)=20
sdldrv.cxx:200: error: 'class Config' has no member named 'player'=20
make[1]: ** [sdldrv.o] Erro 1=20
make[1]: Leaving directory `/home/prog/tuxkart/tuxkart/src'=20
make: ** [all-recursive] Erro 1=20
=20
=20
Cheers,=20
 Ricardo=20
=20
-- =20
O, it is excellent=20
To have a giant's strength; but it is tyrannous=20
To use it like a giant.=20
                -- Shakespeare, "Measure for Measure", II, 2=20
=20
_________________________________________________________
Revista S=E1bado - 12 edi=E7=F5es por um euro - Sem Compromisso=20
clique aqui: http://revistasabado.online.pt

Re: [TuxKart-devel] GOTM release?

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

James Gregory <j....@vi...> writes:

> Well, ideally we don't want to demand people have geforce 2s,

Lowest level that I would care about are TNT2 and MatroxG450, with
reduced LOD level that might be doable.

> however if it's a choice between that, rewriting the whole 3D engine
> or going back to the old kart models, the choice is less clear cut.

The old karts are 400-800 polys, a new medium-LOD kart would be 500
polys, a low-LOD would be ~250, high-LOD 1000-1500. So in case I get
all the karts + LOD levels modeled, we should be more or less save
performance wise and be at a similar level like the old version, well,
at least for the simpler tracks.

>> -We should make the tracks a bit more attractive by adding more
>> background stuff. It would also be a good idea, to add a
>> possibility for skydomes (ie. 6 images projected on an infinitely
>> far-away cube), that typically improves the look alot.

> Well, if you're going to do this then I'm certainly not going to
> complain, but it does strike me that in the time it would take someone
> to make this work, maybe they could have written new AI code or
> something else more vital to the game 's basic playability.

Skydome should be relativly simple from a programming point of view,
the biggest problem I see with them is really how to create them,
since you can't simply draw them in Gimp. Some post-processing in
Blender or so might be needed.

> And is Straver still working on the smoke? If not, then maybe we
> should just remove it (unless of course someone else wants to make
> it look better).

Smoke can be easily disabled in case it doesn't get better, no need to
remove it.

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

Re: [TuxKart-devel] GOTM release?

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

On Thu, 2004-08-26 at 18:20 -0500, Steve Baker wrote:
> Well, tell me what I'm supposed to do.  I disagree strongly with the
> incorporation of additional libraries.   I don't want to enter into
> long pointless arguments about it.  I know that in the end, I'll be
> maintaining this package and it'll be a lot easier to do that if I
> don't have those external dependancies.

I just told you... work on the bits that are not related to the usage of
SDL or SDL_ttf and leave that side of things until later.

Look at the lists people are producing of tasks to be done.  They are
not small and the majority are unrelated to SDL/SDL_ttf.

For a highly paid programmer, you're showing a remarkable lack of
initiative.  I don't know whether to find that incredibly worrying (what
is this world coming to) or incredibly promising (gives me hope of such
lucrative earnings).

I agree, ignore the flame-fest for now.  Focus on the areas where you
are needed most.
-- 
- Charlie

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

Re: [TuxKart-devel] GOTM release?

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

Charles Goodwin wrote:
> On Thu, 2004-08-26 at 17:21 -0500, Steve Baker wrote:
> 
>>>Perhaps if you pitch in *now* rather than after GotM then we'd stand a
>>>chance of achieving our goals.
>>
>>No - I want to wait until I can do it at my own pace without lots
>>of arguments.
> 
> 
> Ugh, that's just... well... frankly it's immature.
> 
> Can't you just focus on things that don't irk you, like performance
> issues or AI or anything.  And then leave the tasks that do bother you
> until later so you can do it at your "own pace".
> 
> *sigh* I won't bring it up again.  Your disinterest is sickening.

Well, tell me what I'm supposed to do.  I disagree strongly with the
incorporation of additional libraries.   I don't want to enter into
long pointless arguments about it.  I know that in the end, I'll be
maintaining this package and it'll be a lot easier to do that if I
don't have those external dependancies.

I could start an enormous flame-fest in an attempt to get these
libraries removed - I could start fighting you guys by reverting
things from CVS - there are lots of completely obnoxious things
I could do...but *those* are all immature things to do - and I won't
do them.

So, I'll wait until you guys are done - and the dust has settled
and I can quietly remove the stuff I don't want and do whatever is
necessary to either add functionality to PLIB or simplify the game
to make that happen.

I'm just not going to get into a huge, stressful argument about it
and if I start doing it now, it'll just slow you guys down and cause
you much more inconvenience.

---------------------------- 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] GOTM release?

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

 Don't remove it just now. I mean, TuxKart code is still on development and 
someone might improve it. I don't know the code, but it just seems to need 
tweaking, not really a re-write.

 If it still is sucky and you want to make a release, better to just comment 
it out than to remove the code.

Cheers,
 Ricardo

Em Quinta, 26 de Agosto de 2004 15:43, o Matze Braun escreveu:
> On Wed, 25 Aug 2004, James Gregory wrote:
> -Kart smoke looks very ugly. We should either improve or remove it,
>  currently it doesn't look good...

-- 
If the odds are a million to one against something occurring, chances
are 50-50 it will.

Re: [TuxKart-devel] GOTM release?

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

On Thu, 2004-08-26 at 17:21 -0500, Steve Baker wrote:
> > Perhaps if you pitch in *now* rather than after GotM then we'd stand a
> > chance of achieving our goals.
> 
> No - I want to wait until I can do it at my own pace without lots
> of arguments.

Ugh, that's just... well... frankly it's immature.

Can't you just focus on things that don't irk you, like performance
issues or AI or anything.  And then leave the tasks that do bother you
until later so you can do it at your "own pace".

*sigh* I won't bring it up again.  Your disinterest is sickening.
-- 
- Charlie

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

Re: [TuxKart-devel] GOTM release?

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

Charles Goodwin wrote:
> On Wed, 2004-08-25 at 20:20 -0500, Steve Baker wrote:

> Perhaps if you pitch in *now* rather than after GotM then we'd stand a
> chance of achieving our goals.

No - I want to wait until I can do it at my own pace without lots
of arguments.

---------------------------- 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] GOTM release?

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

On Thu, 2004-08-26 at 15:43, Matze Braun wrote:
> On Wed, 25 Aug 2004, James Gregory wrote:

> > - FPS issues. Grumbel said he hacked a patch for VBO support into
> > TuxKart, are you going to commit it grumbel or is it too buggy? Also,
> > maybe we could reduce the default number of karts in a race to perhaps
> > 6? Even with double the FPS the game will still struggle on slower
> > computers as it now stands.
> I think we need more research in this area. At the moment it seems we're 
> not using any culling at all, which results in the whole track getting 
> always fed to the 3d hardware.
> VBO might be an option (if plib isn't getting ready for it soon enough, 
> then we could implement a custom VBOVtxTable or something in tuxkart). 
> However you should keep in mind that VBO is only available on 
> geforce2-class hardware, would this be our target audience?

Well, ideally we don't want to demand people have geforce 2s, however if
it's a choice between that, rewriting the whole 3D engine or going back
to the old kart models, the choice is less clear cut.

> -transparent parts in the subsea track are not z-sorted. So sometimes you 
>  don't see the stuff behind the transparent parts...
> -Kart smoke looks very ugly. We should either improve or remove it, 
>  currently it doesn't look good...

> -We should make the tracks a bit more attractive by adding more 
>  background stuff. It would also be a good idea, to add a possibility for 
>  skydomes (ie. 6 images projected on an infinitely far-away cube), that 
>  typically improves the look alot.

Well, if you're going to do this then I'm certainly not going to
complain, but it does strike me that in the time it would take someone
to make this work, maybe they could have written new AI code or
something else more vital to the game 's basic playability.

> -physics is totally pointless at the moment: no sliding, breaking or only 
>  drawing skidmarks when the kart is really skidding. Also the collision 
>  feedback didn't improve (velocity is simply set to 0 which feeld odd).
> -in-game gui is still not nice

Hopefully I'll have time to change round the in-game GUI to SDL_ttf this
weekend, and then maybe I can make minor adjustments each weekday
evening.

> -specials disappeared
> 
> all in all we totally lack a funny gameplay at the moment, our first goal 
> should be to get the game into a state where it is fun to play. So I think 
> our first goals should be to improve the physics and bringing back AI, 
> special and the different game modes.
> The rest should come by itself then I think...

Concerning physics (and the AI which depends on it): is Straver still
working on this? Or can someone just dive in and rewrite the physics
code as they see fit?

And is Straver still working on the smoke? If not, then maybe we should
just remove it (unless of course someone else wants to make it look
better).

	James

Re: [TuxKart-devel] GOTM release?

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

 Just want to add two important points to the list:

- Physics - Turning, acceleration, steering, etc. should be tuned. It is much 
better than it was a couple of weeks ago, but it still isn't that fun.

- Collisions - They seem to be a bit worse than they were before Gotm - just 
try to climb stuff and collide with some stuff. And stuff like water or lava 
should affect somehow the player, even if it is to kill him. Also holes 
should put the player back to the track - with a delay as drawback, 
obviously.

Cheers,
 Ricardo

Em Quarta, 25 de Agosto de 2004 23:25, o James Gregory escreveu:
> Well, it's a little less than a week until the originally proposed
> release date for GOTM.
>
> I assume we're extending the target date? Even so, it might be nice if
> we had a definite list of what we will and won't be doing and who will
> be doing it, and sticking to our list as much as possible so we don't
> end up with new half-finished features/multiple people working on fixing
> the same small problems, otherwise this is going to go on for ever.
>
> Also, if Steve is still refusing to use the Tuxkart Sourceforge account
> to host a download (Steve?) has anyone got any ideas about where else it
> might be hosted?
>
> A list of what I can see really needs fixing before a release (much of
> this is already in the wiki):
>
> - AI!!! Still noone has touched this...
> - Grand Prix mode and saving best race times, grumbel seems to be on the
> case with this
> - FPS issues. Grumbel said he hacked a patch for VBO support into
> TuxKart, are you going to commit it grumbel or is it too buggy? Also,
> maybe we could reduce the default number of karts in a race to perhaps
> 6? Even with double the FPS the game will still struggle on slower
> computers as it now stands.
> - sometimes the kart models flick right round, grumbel said this was
> just a rounding error and he could fix this in a few minutes though?
> - The tire tracks are sometimes blue? Plus on some tracks they just look
> messy (I'm thinking Star Track/Gown's Bow in particular here), maybe it
> could be a track-defined option as to whether they get used?
> - Tire tracks appear even if a kart is currently airborne
> - Though you can't see that you are leaving them, if you reverse you can
> see that tire tracks are left even when you are on a straight
> - Input configuration should be finished. I started but people were
> telling me I was doing it wrong so I left it. Should I finish off the
> job or is someone else going to do it the way they want it done?
> - Why do karts start off in the air before a race begins? Is it some
> hack to avoid having to work out exactly what height karts have to be
> placed at? Even if it is, it looked silly to begin with, and with the
> new start sequence it looks even sillier
> - The smoke coming out of karts is, apart from anything else, too big,
> it makes the karts look really messy and polluting, when they're
> supposed to look cute and cartoony
> - The text in some of the menu screens is too small but fixing this is a
> 5 minute job
> - maybe all the Race GUI stuff could be converted to use the widget set
> and SDL_ttf, or is this not worth it?
> - The new tracks don't have track data
> - the old TuxKart had a bug whereby it often couldn't keep track of laps
> correctly, I guess it's probably still there
> - depite what "pole" has written in the wiki, keyboard input still isn't
> inter-polated
> - I can see through the head of the new Penny model
> - Game probably still memory leaks a shed load when you quit a race
>
> Blimey that's a lot of stuff.
>
> 	James
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel

-- 
Has anyone ever tasted an "end"?  Are they really bitter?

Re: [TuxKart-devel] GOTM release?

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

On Wed, 25 Aug 2004, James Gregory wrote:

> Well, it's a little less than a week until the originally proposed
> release date for GOTM.
> 
> I assume we're extending the target date? Even so, it might be nice if
> we had a definite list of what we will and won't be doing and who will
> be doing it, and sticking to our list as much as possible so we don't
> end up with new half-finished features/multiple people working on fixing
> the same small problems, otherwise this is going to go on for ever.
To me it seems like we need at least 1 more likely 2 extra months... I 
must admit that I didn't really get into the code yet so that I could 
fully concentrate on a single thing and make it perfect...

> 
> Also, if Steve is still refusing to use the Tuxkart Sourceforge account
> to host a download (Steve?) has anyone got any ideas about where else it
> might be hosted?
> 
> A list of what I can see really needs fixing before a release (much of
> this is already in the wiki):
> 
> - AI!!! Still noone has touched this...
> - Grand Prix mode and saving best race times, grumbel seems to be on the
> case with this
> - FPS issues. Grumbel said he hacked a patch for VBO support into
> TuxKart, are you going to commit it grumbel or is it too buggy? Also,
> maybe we could reduce the default number of karts in a race to perhaps
> 6? Even with double the FPS the game will still struggle on slower
> computers as it now stands.
I think we need more research in this area. At the moment it seems we're 
not using any culling at all, which results in the whole track getting 
always fed to the 3d hardware.
VBO might be an option (if plib isn't getting ready for it soon enough, 
then we could implement a custom VBOVtxTable or something in tuxkart). 
However you should keep in mind that VBO is only available on 
geforce2-class hardware, would this be our target audience?

> - sometimes the kart models flick right round, grumbel said this was
> just a rounding error and he could fix this in a few minutes though?
> - The tire tracks are sometimes blue? Plus on some tracks they just look
> messy (I'm thinking Star Track/Gown's Bow in particular here), maybe it
> could be a track-defined option as to whether they get used?
> - Tire tracks appear even if a kart is currently airborne
> - Though you can't see that you are leaving them, if you reverse you can
> see that tire tracks are left even when you are on a straight
> - Input configuration should be finished. I started but people were
> telling me I was doing it wrong so I left it. Should I finish off the
> job or is someone else going to do it the way they want it done?
> - Why do karts start off in the air before a race begins? Is it some
> hack to avoid having to work out exactly what height karts have to be
> placed at? Even if it is, it looked silly to begin with, and with the
> new start sequence it looks even sillier
> - The smoke coming out of karts is, apart from anything else, too big,
> it makes the karts look really messy and polluting, when they're
> supposed to look cute and cartoony
> - The text in some of the menu screens is too small but fixing this is a
> 5 minute job
> - maybe all the Race GUI stuff could be converted to use the widget set
> and SDL_ttf, or is this not worth it?
> - The new tracks don't have track data
> - the old TuxKart had a bug whereby it often couldn't keep track of laps
> correctly, I guess it's probably still there
> - depite what "pole" has written in the wiki, keyboard input still isn't
> inter-polated
> - I can see through the head of the new Penny model
> - Game probably still memory leaks a shed load when you quit a race

-transparent parts in the subsea track are not z-sorted. So sometimes you 
 don't see the stuff behind the transparent parts...
-Kart smoke looks very ugly. We should either improve or remove it, 
 currently it doesn't look good...
-We should make the tracks a bit more attractive by adding more 
 background stuff. It would also be a good idea, to add a possibility for 
 skydomes (ie. 6 images projected on an infinitely far-away cube), that 
 typically improves the look alot.
-physics is totally pointless at the moment: no sliding, breaking or only 
 drawing skidmarks when the kart is really skidding. Also the collision 
 feedback didn't improve (velocity is simply set to 0 which feeld odd).
-in-game gui is still not nice
-specials disappeared

all in all we totally lack a funny gameplay at the moment, our first goal 
should be to get the game into a state where it is fun to play. So I think 
our first goals should be to improve the physics and bringing back AI, 
special and the different game modes.
The rest should come by itself then I think...

Greetings,
	Matze

Re: [TuxKart-devel] GOTM release?

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

On Wed, 2004-08-25 at 20:20 -0500, Steve Baker wrote:
> After you guys are done - I'm going to take a look at what I want to continue
> to support.  If it's not too much effort, I'll be ripping out all of the SDL
> nonsense - reverting menu systems and image loaders to use PLIB...generally
> getting rid of the unnecessarily awkard stuff.

Hopefully you'll be fixing plib with regards to the issues that SDL has
been used to solve rather than just ripping out SDL for the sake of it.

> If you guys would pitch in to fix that, we could get a release that we'd
> all agree on.

Perhaps if you pitch in *now* rather than after GotM then we'd stand a
chance of achieving our goals.
-- 
- Charlie

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

Re: [TuxKart-devel] GOTM release?

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

James Gregory wrote:

> Also, if Steve is still refusing to use the Tuxkart Sourceforge account
> to host a download (Steve?) has anyone got any ideas about where else it
> might be hosted?

After you guys are done - I'm going to take a look at what I want to continue
to support.  If it's not too much effort, I'll be ripping out all of the SDL
nonsense - reverting menu systems and image loaders to use PLIB...generally
getting rid of the unnecessarily awkard stuff.

If you guys would pitch in to fix that, we could get a release that we'd
all agree on.

Then I'll make a proper release and go back to maintaining it.

I won't maintain a version that depends on a bunch of other libraries
though. I know from VERY painful experience how my email in-box will
look if we do that.

> - FPS issues. Grumbel said he hacked a patch for VBO support into
> TuxKart, are you going to commit it grumbel or is it too buggy?

I would be suprised if this patch improved frame rates on all graphics
card types - but if it does, then it should be rolled into PLIB and
not be a TuxKart-only thing.

---------------------------- 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] GOTM release?

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

James Gregory <j....@vi...> writes:

> Well, it's a little less than a week until the originally proposed
> release date for GOTM.
>
> I assume we're extending the target date?

I would suggest another two weeks or something like that.

> Also, if Steve is still refusing to use the Tuxkart Sourceforge
> account to host a download (Steve?) has anyone got any ideas about
> where else it might be hosted?

Finding hosting should be a non-issue, enough free hosting services
around.

> - Grand Prix mode and saving best race times, grumbel seems to be on
> the case with this

Yep, shouldn't be to hard to get it working completly, just needs some
more stuff to gather the times and to display them. Without AI we are
however in serious throuble.

> - FPS issues. Grumbel said he hacked a patch for VBO support into
> TuxKart, are you going to commit it grumbel or is it too buggy?

The 'patch', available at http://pingus.seul.org/~grumbel/tmp/ssg.zip,
is against plib1.6 and basically replaces ssgVtxTabel and something
else and adds multitexture, multicolor support along with VBO and
maybe some other stuff, I havn't had a closer look at it, but just
copied it over to a recent plib and changed some compile throubles to
get it working. It doubles the performance, but particles and colors
in the character view are kind of broken. Its also against plib1.6 I
think, so it might some additional work to cleanly integrate with
plib1.8.

My OpenGL knowledge is rather limited, so if somebody else could have
a look at it, that might be helpfull. Would be a shame to give up the
factor 2 speed improvement.

> Also, maybe we could reduce the default number of karts in a race to
> perhaps 6? Even with double the FPS the game will still struggle on
> slower computers as it now stands.

Some of the current characters (ie. sushi) are still extremly high
poly, I am currently stretching them all down to 1000 polys, with
probally two LOD levels (500, 200). After that performance should be
more useable. For lower end PCs we could then just switch the default
LOD level down to make the game more playable, using good old fog will
of course help too.

> - sometimes the kart models flick right round, grumbel said this was
> just a rounding error and he could fix this in a few minutes though?

Havn't had looked at it, but I guess its the relaxation code for the
kart position that 'relaxes' a angle of >360 in the wrong direction
than it should, fmod() might help.

> - The tire tracks are sometimes blue? Plus on some tracks they just
> look messy (I'm thinking Star Track/Gown's Bow in particular here),
> maybe it could be a track-defined option as to whether they get
> used?

The tire tracks look broken because they aren't marked as
'transparent', so plib draws them in the wrong order, leading to those
transparency artefacts. Should be easily fixable with a deeper look
into the plib manual.

> - Tire tracks appear even if a kart is currently airborne

Tiretracks are also not aligned to the track and apear on all
steering, instead of only on highspeed + drift situations.

> - Why do karts start off in the air before a race begins? Is it some
> hack to avoid having to work out exactly what height karts have to
> be placed at? Even if it is, it looked silly to begin with, and with
> the new start sequence it looks even sillier

Its a hack that needs fixing, calculating the height of the track is
however not so difficult, it just needs to be done at startup so that
the karts can be placed correctly.

> - The smoke coming out of karts is, apart from anything else, too big,
> it makes the karts look really messy and polluting, when they're
> supposed to look cute and cartoony

smoke needs to be much more transparent, much more random, come from
the right places (ie. exhausts) from the kart and should act
differently when you accelarate (ie. more smoke at startup, then back
to a lower smoke level).

> - maybe all the Race GUI stuff could be converted to use the widget
> set and SDL_ttf, or is this not worth it?

Its worth it, the current RaceGUI font is pretty pixely and ugly.

> - The new tracks don't have track data

Some have, some however have buggy or reversed data, its however
relativly easy to generate, bigger problem is that basically all
tracks suck, since the physics is still not all that good and
fine-tuning tracks without final physics is a bit difficult.

> - the old TuxKart had a bug whereby it often couldn't keep track of laps
> correctly, I guess it's probably still there

Basically the whole track meta-data is still just a list of waypoints,
so the detection is naturally a bit buggy. Might be worth to switch
that to something more descriptive, but that basically goes hand in
hand with the AI.

> - I can see through the head of the new Penny model

Reversed normal, easy to fix on the model.

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

[TuxKart-devel] GOTM release?

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

Well, it's a little less than a week until the originally proposed
release date for GOTM.

I assume we're extending the target date? Even so, it might be nice if
we had a definite list of what we will and won't be doing and who will
be doing it, and sticking to our list as much as possible so we don't
end up with new half-finished features/multiple people working on fixing
the same small problems, otherwise this is going to go on for ever.

Also, if Steve is still refusing to use the Tuxkart Sourceforge account
to host a download (Steve?) has anyone got any ideas about where else it
might be hosted?

A list of what I can see really needs fixing before a release (much of
this is already in the wiki):

- AI!!! Still noone has touched this...
- Grand Prix mode and saving best race times, grumbel seems to be on the
case with this
- FPS issues. Grumbel said he hacked a patch for VBO support into
TuxKart, are you going to commit it grumbel or is it too buggy? Also,
maybe we could reduce the default number of karts in a race to perhaps
6? Even with double the FPS the game will still struggle on slower
computers as it now stands.
- sometimes the kart models flick right round, grumbel said this was
just a rounding error and he could fix this in a few minutes though?
- The tire tracks are sometimes blue? Plus on some tracks they just look
messy (I'm thinking Star Track/Gown's Bow in particular here), maybe it
could be a track-defined option as to whether they get used?
- Tire tracks appear even if a kart is currently airborne
- Though you can't see that you are leaving them, if you reverse you can
see that tire tracks are left even when you are on a straight
- Input configuration should be finished. I started but people were
telling me I was doing it wrong so I left it. Should I finish off the
job or is someone else going to do it the way they want it done?
- Why do karts start off in the air before a race begins? Is it some
hack to avoid having to work out exactly what height karts have to be
placed at? Even if it is, it looked silly to begin with, and with the
new start sequence it looks even sillier
- The smoke coming out of karts is, apart from anything else, too big,
it makes the karts look really messy and polluting, when they're
supposed to look cute and cartoony
- The text in some of the menu screens is too small but fixing this is a
5 minute job
- maybe all the Race GUI stuff could be converted to use the widget set
and SDL_ttf, or is this not worth it?
- The new tracks don't have track data
- the old TuxKart had a bug whereby it often couldn't keep track of laps
correctly, I guess it's probably still there
- depite what "pole" has written in the wiki, keyboard input still isn't
inter-polated
- I can see through the head of the new Penny model
- Game probably still memory leaks a shed load when you quit a race

Blimey that's a lot of stuff.

	James

[TuxKart-devel] Multiplayer is broken

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

Just in case you haven't notice,
 two player gaming no longer works.

At least, only one player is displayed and the screen isn't split.

Starting 3-4 multiplayer races/grand prix causes the game to "crash" with the
message: "More than 200 hooknodes in database!".

-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] Re: [Tuxkart-cvs] tuxkart/src WidgetSet.cxx,1.8,1.9

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

 --- "r. mutt" <anj...@ya...> wrote: 
> 
> checking for x/y == 0 is necessary for digital
> sticks/pads to work properly
> (because they jump from 0 to +/-maximum)
> otherwise you get a single movement out of them
> before
> they go dead.
> and yes,
> if x/y is 0 then it will be between -JOY_MID and
> +JOY_MID, but when x/y isn't 0 we still need the old
> test for better analog support
> (stick doesn't have to go all the way back to
> center).
> 
> in my testing w/ the if(!y || -JOY_MID <= y && y <=
> +JOY_MID)
> i had no side-effects w/ analog support
> and the digital worked fine
> if you have a fix for digital pad support you like
> better, i'm certainly ok w/ it.
> 
> -paul

I see what you are trying to do now, and if you say it
works then that's good and I'm happy to leave it. It's
just that with no commit message it wasn't very
obvious what you were trying to do given that
originally "!x" was taken to mean "no movement in the
x axis", and you've now changed it to mean "x axis at
0".

    James

Re: [TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src WidgetSet.cxx,1.8,1.9

[r. m. <anj...@ya...>]

> > > Modified Files:
> > >       WidgetSet.cxx 
> > > Log Message:
> > > %1
> > > 

i just noticed that the script i've been using for
commits was using %1 instead of $1 which of course
meant the my descriptions of changes weren't being
sent, but instead the rather opaque '%1' which might
explain the misunderstanding.
my apologies.

-paul


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: [TuxKart-devel] Re: [Tuxkart-cvs] tuxkart/src WidgetSet.cxx,1.8,1.9

[r. m. <anj...@ya...>]

--- James Gregory <jam...@bt...>
wrote:

> On Sun, 2004-08-22 at 06:51,
> tux...@li...
> wrote:
> > Update of /cvsroot/tuxkart/tuxkart/src
> > In directory
> sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23256/src
> > 
> > Modified Files:
> >       WidgetSet.cxx 
> > Log Message:
> > %1
> > 
> > Index: WidgetSet.cxx
> >
>
===================================================================
>      /* Find a new active widget in the direction
> of
> joystick motion. */
>  
> -    if (x && -JOY_MID <= x && x <= +JOY_MID)
> +    if (!x || -JOY_MID <= x && x <= +JOY_MID)
 
> The reason that it originally checked to make sure x
> was true is that a
> value of 0 for an axis doesn't mean "stick is
> central", rather it means
> "the motion event was not in this axis".
> 
> See sdldrv.cxx:
> 
> int x = 0;
> int y = 0;
>                         
> if (event.jaxis.axis == 0)
>         x = event.jaxis.value;
> else if (event.jaxis.axis == 1)
>         y = event.jaxis.value;
> if (gui)
>         gui -> stick ( x,  y );
> 
> N.B. even a value of 0 did mean "stick is central"
> then testing for !x
> would still be pointless, as unless you have some
> very
> crazy constants
> when x == 0 then -JOY_MID <= x && x <= +JOY_MID will
> always be true. 
> 
>         James

checking for x/y == 0 is necessary for digital
sticks/pads to work properly
(because they jump from 0 to +/-maximum)
otherwise you get a single movement out of them before
they go dead.
and yes,
if x/y is 0 then it will be between -JOY_MID and
+JOY_MID, but when x/y isn't 0 we still need the old
test for better analog support
(stick doesn't have to go all the way back to center).

in my testing w/ the if(!y || -JOY_MID <= y && y <=
+JOY_MID)
i had no side-effects w/ analog support
and the digital worked fine
if you have a fix for digital pad support you like
better, i'm certainly ok w/ it.

-paul


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [TuxKart-devel] Player's position icons [patch]

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

Thank you, Steve.

Ricardo

Em Domingo, 22 de Agosto de 2004 18:53, o Steve Baker escreveu:
> Ricardo Cruz wrote:
> >  Steven, may I get CVS access? My sourceforge nickname is rmcruz . Thx!
>
> Sure - Welcome to the project!


-- 
A truth that's told with bad intent
Beats all the lies you can invent.
		-- William Blake