tuxkart-devel Mailing List for Tux Kart (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I don't quite understand how public wikis can prevent this sort of
thing.

	James

Just double checked on the compare issue. Seems like older
gcc ain't compliant to ansi. :-( and lib definition changed.

How about just working around that and using something like
   memcmp(lhs.c_str(), rhs.c_str(), lhs.length() - rhs.length())==0

Red.

On Wed, 2004-10-20 at 21:57, Red Zebra wrote:
  > Hi,
  >
  > Not sure this is the right channel but I just compiled the latest CVS.
  > I had to made some small changes for compatiblility in order to
  > compile with 2.95.3. (running gentoo)  None of these should break
  > anything and are very straight forward
  >
  > If someone would be so nice to add them or let me doit that would be
  > nice before the next official release.
  >
  > So here I go
  >
  > --------------------------------------------------------------
  > /cvsroot/tuxkart/tuxkart/src/KartManager.cxx
  > /cvsroot/tuxkart/tuxkart/src/RaceManager.cxx
  > /cvsroot/tuxkart/tuxkart/src/StringUtils.cxx
  > /cvsroot/tuxkart/tuxkart/src/World.cxx
  >
  > had to add :
  >          #include <algorithm>

  Committed...

  > ------------------------------------------------------------
  > /cvsroot/tuxkart/tuxkart/src/start_tuxkart.cxx
  > replace: and by &&
  > replace: or  by ||

  Committed...

  > --------------------------------------------------------------
  > /cvsroot/tuxkart/tuxkart/src/StringUtils.cxx
  >
  > <     return lhs.compare(lhs.length() - rhs.length(), rhs.length(), 
rhs) ==
  >  >     return lhs.compare(rhs, lhs.length() - rhs.length(), 
rhs.length()) ==
  >
  > none of the compare methods seems std++ ?

  Not committed (at least by me, someone else might commit it) because
  according to "The C++ Programming Language" compare can take:

  const basic_string&
  const Ch*
  size_type, size_type, const basic_string&
  size_type, size_typ[e, const basic_string&, size_type, size_type
  size_type, size_type, const Ch*, size_type

  Currently it uses the 3rd one, your one doesn"t seem to be there, so I"m
  not quite sure if that would fix more problems than it would create?

  > --------------------------------------------------------------
  > /cvsroot/tuxkart/tuxkart/src/lisp/Lexer.cxx
  >
  > std::streamsize n = stream.readsome(buffer, BUFFER_SIZE);
  >
  > This is a bit different. readsome is not availabel in older
  > versions so I replaced it with
  >          stream.reads(buffer, BUFFER_SIZE);
  >          std::streamsize n = stream.gcount();
  > Which should be exactly the same. However if that"s realy the case then
  > there might be an error in the 2 places a bit further where there
  > is an check fo stream.eof. because then stream.eof would be true
  > before c is at the end of the read buffer. (stream is already read
  > and reached the end but there"s still data there.) So I
  > had to put the stream.eof check to ( while(1) and if (0) )

  I"ll leave someone else who understands that code to deal with that.

  Thanks,

  	James

On Wed, 2004-10-20 at 21:57, Red Zebra wrote:
> Hi,
> 
> Not sure this is the right channel but I just compiled the latest CVS.
> I had to made some small changes for compatiblility in order to
> compile with 2.95.3. (running gentoo)  None of these should break 
> anything and are very straight forward
> 
> If someone would be so nice to add them or let me doit that would be
> nice before the next official release.
> 
> So here I go
> 
> --------------------------------------------------------------
> /cvsroot/tuxkart/tuxkart/src/KartManager.cxx
> /cvsroot/tuxkart/tuxkart/src/RaceManager.cxx
> /cvsroot/tuxkart/tuxkart/src/StringUtils.cxx
> /cvsroot/tuxkart/tuxkart/src/World.cxx
> 
> had to add :
>          #include <algorithm>

Committed...

> ------------------------------------------------------------
> /cvsroot/tuxkart/tuxkart/src/start_tuxkart.cxx
> replace: and by &&
> replace: or  by ||

Committed...

> --------------------------------------------------------------
> /cvsroot/tuxkart/tuxkart/src/StringUtils.cxx
> 
> <     return lhs.compare(lhs.length() - rhs.length(), rhs.length(), rhs) ==
>  >     return lhs.compare(rhs, lhs.length() - rhs.length(), rhs.length()) ==
> 
> none of the compare methods seems std++ ?

Not committed (at least by me, someone else might commit it) because
according to "The C++ Programming Language" compare can take:

const basic_string&
const Ch*
size_type, size_type, const basic_string&
size_type, size_typ[e, const basic_string&, size_type, size_type
size_type, size_type, const Ch*, size_type

Currently it uses the 3rd one, your one doesn't seem to be there, so I'm
not quite sure if that would fix more problems than it would create?

> --------------------------------------------------------------
> /cvsroot/tuxkart/tuxkart/src/lisp/Lexer.cxx
> 
> std::streamsize n = stream.readsome(buffer, BUFFER_SIZE);
> 
> This is a bit different. readsome is not availabel in older
> versions so I replaced it with
>          stream.reads(buffer, BUFFER_SIZE);
>          std::streamsize n = stream.gcount();
> Which should be exactly the same. However if that's realy the case then
> there might be an error in the 2 places a bit further where there
> is an check fo stream.eof. because then stream.eof would be true
> before c is at the end of the read buffer. (stream is already read
> and reached the end but there's still data there.) So I
> had to put the stream.eof check to ( while(1) and if (0) )

I'll leave someone else who understands that code to deal with that.

Thanks,

	James

Hi,

Not sure this is the right channel but I just compiled the latest CVS.
I had to made some small changes for compatiblility in order to
compile with 2.95.3. (running gentoo)  None of these should break 
anything and are very straight forward

If someone would be so nice to add them or let me doit that would be
nice before the next official release.

So here I go

--------------------------------------------------------------
/cvsroot/tuxkart/tuxkart/src/KartManager.cxx
/cvsroot/tuxkart/tuxkart/src/RaceManager.cxx
/cvsroot/tuxkart/tuxkart/src/StringUtils.cxx
/cvsroot/tuxkart/tuxkart/src/World.cxx

had to add :
         #include <algorithm>
------------------------------------------------------------
/cvsroot/tuxkart/tuxkart/src/start_tuxkart.cxx
replace: and by &&
replace: or  by ||
--------------------------------------------------------------
/cvsroot/tuxkart/tuxkart/src/StringUtils.cxx

<     return lhs.compare(lhs.length() - rhs.length(), rhs.length(), rhs) ==
 >     return lhs.compare(rhs, lhs.length() - rhs.length(), rhs.length()) ==

none of the compare methods seems std++ ?
--------------------------------------------------------------
/cvsroot/tuxkart/tuxkart/src/lisp/Lexer.cxx

std::streamsize n = stream.readsome(buffer, BUFFER_SIZE);

This is a bit different. readsome is not availabel in older
versions so I replaced it with
         stream.reads(buffer, BUFFER_SIZE);
         std::streamsize n = stream.gcount();
Which should be exactly the same. However if that's realy the case then
there might be an error in the 2 places a bit further where there
is an check fo stream.eof. because then stream.eof would be true
before c is at the end of the read buffer. (stream is already read
and reached the end but there's still data there.) So I
had to put the stream.eof check to ( while(1) and if (0) )

--------------------------------------------------------------

After all of this the games runs nicely and looks real good :-)

red.

On Sun, 17 Oct 2004 18:57:32 -0400, Eduardo Hern=C3=A1ndez
<cos...@ho...> wrote:
> I'm planning to add some AI. Details on the tuxkart wiki.. Game Design ->=
 AI

That sounds good. Nobody is actively working on AI.

To get SF dev access, message a request to this list with your
sourceforge username.

--=20
Ryan

I'm planning to add some AI. Details on the tuxkart wiki.. Game Design -> AI

_________________________________________________________________
MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/

I just wanted to know what each developer is working on..

_________________________________________________________________
Las mejores tiendas, los precios mas bajos, entregas en todo el mundo, 
YupiMSN Compras: http://latam.msn.com/compras/

James Gregory wrote:
> On Mon, 2004-10-11 at 23:35, Steve Baker wrote:
 >
>>However, if you delete one window *then* create the other - then you'll
>>certainly have to reload the textures - which would definitely be a PITA. 
> 
> It's very, very tempting to think you're trying to be funny. SDL doesn't
> support multiple windows.

No - actually, I don't use SDL - I wasn't aware of that limitation.

But if I *had* thought of it, it would have been a pretty on-the-mark
criticism!  :-)

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

 I personally like the jump key ever since I saw it in an old racing arcade 
game. I think it would be fun to have it on TuxKart.
 By the way, I haven't checked it lately, but it was working some time ago...

Cheers,
 Ricardo

Em Segunda, 11 de Outubro de 2004 21:23, o Matze Braun escreveu:
> On Mon, 11 Oct 2004, James Gregory wrote:
> > On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> > Also, either fix or remove jump.
>
> I'd say remove, jumping is relatively useless and feels strange IMO...
>
-- 
You buttered your bread, now lie in it.

Em Segunda, 11 de Outubro de 2004 15:45, o James Gregory escreveu:
> On Mon, 2004-10-11 at 13:51, Ricardo Cruz wrote:
> > Em Segunda, 11 de Outubro de 2004 13:18, o James Gregory escreveu:
> > > On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> > > >  same goes for sound and display settings). A display setting for
> > > >  resolution and fullscreen would be a good idea though.
> > >
> > > Adding in a menu button called "fullscreen" is easy, but as far as I
> > > know when you do something like switch to/from fullscreen you have to
> > > reload all textures, which means someone who knows OpenGL/Plib would
> > > need to do it.
> >
> >  No, you don't. Just call: SDL_SetVideoMode(); and feed that to the
> > screen Surface, if any exists.
> >  You might have to do that, but for change of resolutions. Even then, I
> > don't think you need.
> >
> >  By the way, SDL_WM_ToggleFullScreen(); might be a more friendly call,
> > but it only works on X11.
>
> You evidently understand it better than I do, so feel free to add it.
>
 Well, it looks like you have to reload all textures again afterall.
 Anyway, since you know the buttons code better than anyone else, maybe you 
could add that button and then call an empty function. Then, somebody else 
would write the necessary code for the function.

> >  No, you're wrong, they are needed. Instead of had removing them
> > (something that you seem delighted to do), you should had improved them,
> > by adding a different color, size or an icon.
>
> You think I'm wrong, I think I'm right. Nonetheless, if you want to put
> them back, feel free, as I'm bored of arguing.
>
 Pressing Esc to open/close a menu or quit is something that anyone is 
confortable with, but not really to go back to the previous menu.
 Besides, the target of the game should be ordinary ppl with no to little 
computer knowledge, and believe me when I say that an ordinary person doesn't 
know the keyboard layout that well.
 Especially, since, at least in Portugal, English key names are not translated 
- including the Esc key. You might argue that they have to know English to 
play the game, but believe me that it is much easier to understand a full 
text than a short text for something, Esc -> Escape.

Cheers,
 Ricardo

> 	James
>

-- 
	A man walked into a bar with his alligator and asked the bartender,
"Do you serve lawyers here?".
	"Sure do," replied the bartender.
	"Good," said the man.  "Give me a beer, and I'll have a lawyer for
my 'gator."

On Mon, 2004-10-11 at 23:35, Steve Baker wrote:
> James Gregory wrote:
> 
> > Adding in a menu button called "fullscreen" is easy, but as far as I
> > know when you do something like switch to/from fullscreen you have to
> > reload all textures, which means someone who knows OpenGL/Plib would
> > need to do it.
> 
> You ought to be able to open a second window which shares resources with
> the first one - then delete the first window.  If resources are shared
> then you shouldn't have to reload textures.
> 
> However, if you delete one window *then* create the other - then you'll
> certainly have to reload the textures - which would definitely be a PITA.

It's very, very tempting to think you're trying to be funny. SDL doesn't
support multiple windows.

	James

James Gregory wrote:

> Adding in a menu button called "fullscreen" is easy, but as far as I
> know when you do something like switch to/from fullscreen you have to
> reload all textures, which means someone who knows OpenGL/Plib would
> need to do it.

You ought to be able to open a second window which shares resources with
the first one - then delete the first window.  If resources are shared
then you shouldn't have to reload textures.

However, if you delete one window *then* create the other - then you'll
certainly have to reload the textures - which would definitely be a PITA.

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

On Mon, 11 Oct 2004, James Gregory wrote:

> On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> 
> 
> > > - Copying and pasting in the old physics+AI code from the pre-GOTM
> > > Tuxkart, and then just making some minor tweaks to the sensitivity
> of
> > > the handling
> > Well the physics currently in cvs isn't worse than the old physics, so
> it 
> > should be okay to keep it IMO. (Maybe some more tweaking with the 
> > constants could improve it)
> 
> Well, OK, but it would have to be you who did said tweaking, the reason
> I suggested copying and pasting the old code is that it was very simple,
> and hence it would be very simple for anyone to tweak it in a short
> space of time. The same cannot be said for the current code...
It's really not that hard, the values are in the kart profile files and 
there was some debug mode to change them I think.

> 
> Also, either fix or remove jump.
I'd say remove, jumping is relatively useless and feels strange IMO...

> 
> > Yep pushing for a release would be a good idea. I'll have my last exam
> > tomorrow and then I should have a little more time to work on this...
> > There's also other stuff that could easily be worked on:
> > -Fix splitscreen multiplayer
> 
> I thought it already worked fine, but then I just had a quick go to make
> sure and it appears that in multiplayer some tracks segfault when the
> race starts, whilst others don't segfault but it does segfault when you
> exit the race and quit from the main menu. Trying to backtrace the
> in-game crash gave:
> 
> #0  0x452c6067 in ?? ()
> Cannot access memory at address 0x0
> 
> Hmm. Backtracing the on-exit crash gave:
> 
> #0  0x40373d71 in kill () from /lib/i686/libc.so.6
> #1  0x400e8871 in pthread_kill () from /lib/i686/libpthread.so.0
> #2  0x400e8b8b in raise () from /lib/i686/libpthread.so.0
> #3  0x40373b04 in raise () from /lib/i686/libc.so.6
> #4  0x403751e0 in abort () from /lib/i686/libc.so.6
> #5  0x4036d0ad in __assert_fail () from /lib/i686/libc.so.6
> #6  0x08081ae4 in ssgDeRefDelete(ssgBase*) (s=0x400edb84) at ssg.cxx:89
> #7  0x080a0afd in ~ssgVtxTable (this=0x8e42768) at ssgVtxTable.cxx:244
> #8  0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x8e42768) at ssg.cxx:89
> #9  0x08084887 in ssgBranch::removeKid(int) (this=0x8d02698, n=29)
>     at ssgBranch.cxx:97
> #10 0x08084909 in ssgBranch::removeAllKids() (this=0x8d02698)
>     at ssgBranch.cxx:112
> #11 0x080845d7 in ~ssgBranch (this=0x8d02698) at ssgBranch.cxx:59
> #12 0x080d0345 in ~ssgBaseTransform (this=0x0) at
> ssgBaseTransform.cxx:49
> #13 0x08096fc6 in ~ssgTransform (this=0x8d02698) at ssgTransform.cxx:52
> #14 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x1d) at ssg.cxx:89
> #15 0x08084887 in ssgBranch::removeKid(int) (this=0x8e38630, n=0)
>     at ssgBranch.cxx:97
> #16 0x08084909 in ssgBranch::removeAllKids() (this=0x8e38630)
>     at ssgBranch.cxx:112
> #17 0x080845d7 in ~ssgBranch (this=0x8e38630) at ssgBranch.cxx:59
> #18 0x080d0345 in ~ssgBaseTransform (this=0x0) at
> ssgBaseTransform.cxx:49
> #19 0x08096fc6 in ~ssgTransform (this=0x8e38630) at ssgTransform.cxx:52
> #20 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x0) at ssg.cxx:89
> #21 0x08084887 in ssgBranch::removeKid(int) (this=0x8cf3658, n=7)
>     at ssgBranch.cxx:97
> #22 0x08084909 in ssgBranch::removeAllKids() (this=0x8cf3658)
>     at ssgBranch.cxx:112
> #23 0x08084697 in ~ssgBranch (this=0x8cf3658) at ssgBranch.cxx:59
> #24 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x7) at ssg.cxx:89
> #25 0x08084887 in ssgBranch::removeKid(int) (this=0x8d7c8b0, n=0)
>     at ssgBranch.cxx:97
> #26 0x08084909 in ssgBranch::removeAllKids() (this=0x8d7c8b0)
>     at ssgBranch.cxx:112
> #27 0x080845d7 in ~ssgBranch (this=0x8d7c8b0) at ssgBranch.cxx:59
> #28 0x080d0345 in ~ssgBaseTransform (this=0x0) at
> ssgBaseTransform.cxx:49
> #29 0x08096fc6 in ~ssgTransform (this=0x8d7c8b0) at ssgTransform.cxx:52
> #30 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x0) at ssg.cxx:89
> #31 0x08054145 in ~KartProperties (this=0x8b665a0) at
> KartProperties.cxx:88
> #32 0x0805464f in ~KartManager (this=0x81016f8) at KartManager.cxx:37
> #33 0x40376270 in exit () from /lib/i686/libc.so.6
> #34 0x40360c5f in __libc_start_main () from /lib/i686/libc.so.6
> 
> I've no idea how all that ssg stuff works so someone else will have to
> fix it.
That looks like some refcounting is wrong here. Why don't you try to fix 
it yourself? Refusing to learn plib won't really help you when working on 
tuxkart. (Docu about refcounting: 
http://plib.sourceforge.net/ssg/ssgBase.html)

> 
> > -Cleanup main menu (No multiplayer button, if there is no multiplayer
> 
> There is split screen multiplayer, and other than the aforementioned
> segfaulting plus the fact the framerate drops low enough to make it
> unplayable, it works. I should make joystick controls configurable and
> not just keyboard ones, I'll do it once it's clear other people are also
> doing something (as it will be boring).
Well ok, you can still remove/disable network multiplayer and basically 
all buttons that do nothing.

> 
> >  same goes for sound and display settings). A display setting for 
> >  resolution and fullscreen would be a good idea though.
> 
> Adding in a menu button called "fullscreen" is easy, but as far as I
> know when you do something like switch to/from fullscreen you have to
> reload all textures, which means someone who knows OpenGL/Plib would
> need to do it.
From what I've seen it's easily possible to reload all textures. So the 
easiest solution is to abort all main loops, shutdown everything and start 
the app from beginning again.

> 
> > -Add back buttons to the menus
> 
> Someone (I think oaf_thadres) already did this, but then I removed them
> as I thought they looked messy and were unnecessary. You can go back in
> menus by:
I can't comment about the messy, but they surely aren't unnecessary. I 
always wonder for a few seconds how to get back to last screen before I 
find out ESC works. So this is surely bad for userfriendliness.

Greetings,
	Matze

On Mon, 11 Oct 2004, Ricardo Cruz wrote:

> Em Segunda, 11 de Outubro de 2004 13:18, o James Gregory escreveu:
> > On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> > >  same goes for sound and display settings). A display setting for
> > >  resolution and fullscreen would be a good idea though.
> >
> > Adding in a menu button called "fullscreen" is easy, but as far as I
> > know when you do something like switch to/from fullscreen you have to
> > reload all textures, which means someone who knows OpenGL/Plib would
> > need to do it.
> >
>  No, you don't. Just call: SDL_SetVideoMode(); and feed that to the screen 
> Surface, if any exists.
>  You might have to do that, but for change of resolutions. Even then, I don't 
> think you need.
AFAIK you have to reaload textures when switching from windowed into 
fullscreen mode. At least on win32 all textures turned white when doing so 
and on linux I had a xserver crash from time to time when not reloading 
textures. I wasn't able to find an official statement about this, but 
since the openglcontext is completely destroyed and reconstructed when 
switching I assume that you have to reload the textures. An alternative to 
complicated reload stuff would be to shut everything down and start the 
app again from the beginning.

Greetings,
	Matze

On Mon, 2004-10-11 at 13:51, Ricardo Cruz wrote:
> Em Segunda, 11 de Outubro de 2004 13:18, o James Gregory escreveu:
> > On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> > >  same goes for sound and display settings). A display setting for
> > >  resolution and fullscreen would be a good idea though.
> >
> > Adding in a menu button called "fullscreen" is easy, but as far as I
> > know when you do something like switch to/from fullscreen you have to
> > reload all textures, which means someone who knows OpenGL/Plib would
> > need to do it.
> >
>  No, you don't. Just call: SDL_SetVideoMode(); and feed that to the screen 
> Surface, if any exists.
>  You might have to do that, but for change of resolutions. Even then, I don't 
> think you need.
> 
>  By the way, SDL_WM_ToggleFullScreen(); might be a more friendly call, but it 
> only works on X11.

You evidently understand it better than I do, so feel free to add it.

>  No, you're wrong, they are needed. Instead of had removing them (something 
> that you seem delighted to do), you should had improved them, by adding a 
> different color, size or an icon.

You think I'm wrong, I think I'm right. Nonetheless, if you want to put
them back, feel free, as I'm bored of arguing.

	James

As I added in support for joystick configuration it will mess up if it
reads an old config file.

Thanks,

	James

Em Segunda, 11 de Outubro de 2004 13:18, o James Gregory escreveu:
> On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> >  same goes for sound and display settings). A display setting for
> >  resolution and fullscreen would be a good idea though.
>
> Adding in a menu button called "fullscreen" is easy, but as far as I
> know when you do something like switch to/from fullscreen you have to
> reload all textures, which means someone who knows OpenGL/Plib would
> need to do it.
>
 No, you don't. Just call: SDL_SetVideoMode(); and feed that to the screen 
Surface, if any exists.
 You might have to do that, but for change of resolutions. Even then, I don't 
think you need.

 By the way, SDL_WM_ToggleFullScreen(); might be a more friendly call, but it 
only works on X11.

> > -Add back buttons to the menus
>
> Someone (I think oaf_thadres) already did this, but then I removed them
> as I thought they looked messy and were unnecessary. You can go back in
> menus by:
>
> - pressing escape
> - pressing the brake keyboard button
> - pressing the brake joystick button
> - pressing the right mouse button
>
 No, you're wrong, they are needed. Instead of had removing them (something 
that you seem delighted to do), you should had improved them, by adding a 
different color, size or an icon.

 Also something that annoys me is that you can't press Up in the first item 
and go to last, and also press Down on last item to go to first.

Cheers,
 Ricardo
-- 
economist, n:
	Someone who's good with figures, but doesn't have enough
	personality to become an accountant.

 I just want to ask to stop asking to remove stuff! It's just plain stupid and 
revails your ignorance.
 If it is bad implemented, it's one thing. But if it just isn't tweaked or 
polished enough, why not just disable it??

Cheers,
 Ricardo

Em Segunda, 11 de Outubro de 2004 13:18, o James Gregory escreveu:
> On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> > > - Copying and pasting in the old physics+AI code from the pre-GOTM
> > > Tuxkart, and then just making some minor tweaks to the sensitivity
>
> of
>
> > > the handling
> >
> > Well the physics currently in cvs isn't worse than the old physics, so
>
> it
>
> > should be okay to keep it IMO. (Maybe some more tweaking with the
> > constants could improve it)
>
> Well, OK, but it would have to be you who did said tweaking, the reason
> I suggested copying and pasting the old code is that it was very simple,
> and hence it would be very simple for anyone to tweak it in a short
> space of time. The same cannot be said for the current code...
>
> Also, either fix or remove jump.
>
> > Yep pushing for a release would be a good idea. I'll have my last exam
> > tomorrow and then I should have a little more time to work on this...
> > There's also other stuff that could easily be worked on:
> > -Fix splitscreen multiplayer
>
> I thought it already worked fine, but then I just had a quick go to make
> sure and it appears that in multiplayer some tracks segfault when the
> race starts, whilst others don't segfault but it does segfault when you
> exit the race and quit from the main menu. Trying to backtrace the
> in-game crash gave:
>
> #0  0x452c6067 in ?? ()
> Cannot access memory at address 0x0
>
> Hmm. Backtracing the on-exit crash gave:
>
> #0  0x40373d71 in kill () from /lib/i686/libc.so.6
> #1  0x400e8871 in pthread_kill () from /lib/i686/libpthread.so.0
> #2  0x400e8b8b in raise () from /lib/i686/libpthread.so.0
> #3  0x40373b04 in raise () from /lib/i686/libc.so.6
> #4  0x403751e0 in abort () from /lib/i686/libc.so.6
> #5  0x4036d0ad in __assert_fail () from /lib/i686/libc.so.6
> #6  0x08081ae4 in ssgDeRefDelete(ssgBase*) (s=0x400edb84) at ssg.cxx:89
> #7  0x080a0afd in ~ssgVtxTable (this=0x8e42768) at ssgVtxTable.cxx:244
> #8  0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x8e42768) at ssg.cxx:89
> #9  0x08084887 in ssgBranch::removeKid(int) (this=0x8d02698, n=29)
>     at ssgBranch.cxx:97
> #10 0x08084909 in ssgBranch::removeAllKids() (this=0x8d02698)
>     at ssgBranch.cxx:112
> #11 0x080845d7 in ~ssgBranch (this=0x8d02698) at ssgBranch.cxx:59
> #12 0x080d0345 in ~ssgBaseTransform (this=0x0) at
> ssgBaseTransform.cxx:49
> #13 0x08096fc6 in ~ssgTransform (this=0x8d02698) at ssgTransform.cxx:52
> #14 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x1d) at ssg.cxx:89
> #15 0x08084887 in ssgBranch::removeKid(int) (this=0x8e38630, n=0)
>     at ssgBranch.cxx:97
> #16 0x08084909 in ssgBranch::removeAllKids() (this=0x8e38630)
>     at ssgBranch.cxx:112
> #17 0x080845d7 in ~ssgBranch (this=0x8e38630) at ssgBranch.cxx:59
> #18 0x080d0345 in ~ssgBaseTransform (this=0x0) at
> ssgBaseTransform.cxx:49
> #19 0x08096fc6 in ~ssgTransform (this=0x8e38630) at ssgTransform.cxx:52
> #20 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x0) at ssg.cxx:89
> #21 0x08084887 in ssgBranch::removeKid(int) (this=0x8cf3658, n=7)
>     at ssgBranch.cxx:97
> #22 0x08084909 in ssgBranch::removeAllKids() (this=0x8cf3658)
>     at ssgBranch.cxx:112
> #23 0x08084697 in ~ssgBranch (this=0x8cf3658) at ssgBranch.cxx:59
> #24 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x7) at ssg.cxx:89
> #25 0x08084887 in ssgBranch::removeKid(int) (this=0x8d7c8b0, n=0)
>     at ssgBranch.cxx:97
> #26 0x08084909 in ssgBranch::removeAllKids() (this=0x8d7c8b0)
>     at ssgBranch.cxx:112
> #27 0x080845d7 in ~ssgBranch (this=0x8d7c8b0) at ssgBranch.cxx:59
> #28 0x080d0345 in ~ssgBaseTransform (this=0x0) at
> ssgBaseTransform.cxx:49
> #29 0x08096fc6 in ~ssgTransform (this=0x8d7c8b0) at ssgTransform.cxx:52
> #30 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x0) at ssg.cxx:89
> #31 0x08054145 in ~KartProperties (this=0x8b665a0) at
> KartProperties.cxx:88
> #32 0x0805464f in ~KartManager (this=0x81016f8) at KartManager.cxx:37
> #33 0x40376270 in exit () from /lib/i686/libc.so.6
> #34 0x40360c5f in __libc_start_main () from /lib/i686/libc.so.6
>
> I've no idea how all that ssg stuff works so someone else will have to
> fix it.
>
> > -Cleanup main menu (No multiplayer button, if there is no multiplayer
>
> There is split screen multiplayer, and other than the aforementioned
> segfaulting plus the fact the framerate drops low enough to make it
> unplayable, it works. I should make joystick controls configurable and
> not just keyboard ones, I'll do it once it's clear other people are also
> doing something (as it will be boring).
>
> >  same goes for sound and display settings). A display setting for
> >  resolution and fullscreen would be a good idea though.
>
> Adding in a menu button called "fullscreen" is easy, but as far as I
> know when you do something like switch to/from fullscreen you have to
> reload all textures, which means someone who knows OpenGL/Plib would
> need to do it.
>
> > -Add back buttons to the menus
>
> Someone (I think oaf_thadres) already did this, but then I removed them
> as I thought they looked messy and were unnecessary. You can go back in
> menus by:
>
> - pressing escape
> - pressing the brake keyboard button
> - pressing the brake joystick button
> - pressing the right mouse button
>
> Still, I've done enough arguing on this list, if someone really wants to
> put them back again, go ahead.
>
> > -Add a highscore for timetrial (and eventually single race)
> > -Add a score table that is displayed at the end of each race in
> >  championship mode.
> > -Add a credits screen
> > -Fix bullets and specials (probably remove some bad working ones like
>
> the
>
> >  magnet, the rockets and speed powerups should be easy to revive)
> > -give penality when beaming back to the track. (ie. when pressing d or
> >  when you hit a deadly-texture or so). Your car should get beamed back
>
> and
>
> >  blink or fade in for a second or 2 in which you can't drive.
> >
> > These should be all easy tasks to do and are needed for the release to
>
> be
>
> > at least fun to play IMO.
>
> If someone volunteers to do these things, then yes they would add
> greatly to the game and wouldn't be particularly major undertakings. But
> someone would still have to volunteer to do them.
>
>         James
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel

-- 
Keep your Eye on the Ball,
Your Shoulder to the Wheel,
Your Nose to the Grindstone,
Your Feet on the Ground,
Your Head on your Shoulders.
Now... try to get something DONE!

On Mon, 2004-10-11 at 11:24, Matze Braun wrote:
> On Mon, 11 Oct 2004, James Gregory wrote:
> 

Oh, two other things:

1. You currently have to run it from the root directory, i.e.
./src/tuxkart, or otherwise it will fail to load all the textures.
Surely this isn't very hard to fix if you understand how textures are
loaded?

2. Grumbel said that the way the kart keeps flicking round would be easy
to fix. Is it?

	James

On Mon, 2004-10-11 at 11:24, Matze Braun wrote:

> > - Copying and pasting in the old physics+AI code from the pre-GOTM
> > Tuxkart, and then just making some minor tweaks to the sensitivity
of
> > the handling
> Well the physics currently in cvs isn't worse than the old physics, so
it 
> should be okay to keep it IMO. (Maybe some more tweaking with the 
> constants could improve it)

Well, OK, but it would have to be you who did said tweaking, the reason
I suggested copying and pasting the old code is that it was very simple,
and hence it would be very simple for anyone to tweak it in a short
space of time. The same cannot be said for the current code...

Also, either fix or remove jump.

> Yep pushing for a release would be a good idea. I'll have my last exam
> tomorrow and then I should have a little more time to work on this...
> There's also other stuff that could easily be worked on:
> -Fix splitscreen multiplayer

I thought it already worked fine, but then I just had a quick go to make
sure and it appears that in multiplayer some tracks segfault when the
race starts, whilst others don't segfault but it does segfault when you
exit the race and quit from the main menu. Trying to backtrace the
in-game crash gave:

#0  0x452c6067 in ?? ()
Cannot access memory at address 0x0

Hmm. Backtracing the on-exit crash gave:

#0  0x40373d71 in kill () from /lib/i686/libc.so.6
#1  0x400e8871 in pthread_kill () from /lib/i686/libpthread.so.0
#2  0x400e8b8b in raise () from /lib/i686/libpthread.so.0
#3  0x40373b04 in raise () from /lib/i686/libc.so.6
#4  0x403751e0 in abort () from /lib/i686/libc.so.6
#5  0x4036d0ad in __assert_fail () from /lib/i686/libc.so.6
#6  0x08081ae4 in ssgDeRefDelete(ssgBase*) (s=0x400edb84) at ssg.cxx:89
#7  0x080a0afd in ~ssgVtxTable (this=0x8e42768) at ssgVtxTable.cxx:244
#8  0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x8e42768) at ssg.cxx:89
#9  0x08084887 in ssgBranch::removeKid(int) (this=0x8d02698, n=29)
    at ssgBranch.cxx:97
#10 0x08084909 in ssgBranch::removeAllKids() (this=0x8d02698)
    at ssgBranch.cxx:112
#11 0x080845d7 in ~ssgBranch (this=0x8d02698) at ssgBranch.cxx:59
#12 0x080d0345 in ~ssgBaseTransform (this=0x0) at
ssgBaseTransform.cxx:49
#13 0x08096fc6 in ~ssgTransform (this=0x8d02698) at ssgTransform.cxx:52
#14 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x1d) at ssg.cxx:89
#15 0x08084887 in ssgBranch::removeKid(int) (this=0x8e38630, n=0)
    at ssgBranch.cxx:97
#16 0x08084909 in ssgBranch::removeAllKids() (this=0x8e38630)
    at ssgBranch.cxx:112
#17 0x080845d7 in ~ssgBranch (this=0x8e38630) at ssgBranch.cxx:59
#18 0x080d0345 in ~ssgBaseTransform (this=0x0) at
ssgBaseTransform.cxx:49
#19 0x08096fc6 in ~ssgTransform (this=0x8e38630) at ssgTransform.cxx:52
#20 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x0) at ssg.cxx:89
#21 0x08084887 in ssgBranch::removeKid(int) (this=0x8cf3658, n=7)
    at ssgBranch.cxx:97
#22 0x08084909 in ssgBranch::removeAllKids() (this=0x8cf3658)
    at ssgBranch.cxx:112
#23 0x08084697 in ~ssgBranch (this=0x8cf3658) at ssgBranch.cxx:59
#24 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x7) at ssg.cxx:89
#25 0x08084887 in ssgBranch::removeKid(int) (this=0x8d7c8b0, n=0)
    at ssgBranch.cxx:97
#26 0x08084909 in ssgBranch::removeAllKids() (this=0x8d7c8b0)
    at ssgBranch.cxx:112
#27 0x080845d7 in ~ssgBranch (this=0x8d7c8b0) at ssgBranch.cxx:59
#28 0x080d0345 in ~ssgBaseTransform (this=0x0) at
ssgBaseTransform.cxx:49
#29 0x08096fc6 in ~ssgTransform (this=0x8d7c8b0) at ssgTransform.cxx:52
#30 0x08081ac6 in ssgDeRefDelete(ssgBase*) (s=0x0) at ssg.cxx:89
#31 0x08054145 in ~KartProperties (this=0x8b665a0) at
KartProperties.cxx:88
#32 0x0805464f in ~KartManager (this=0x81016f8) at KartManager.cxx:37
#33 0x40376270 in exit () from /lib/i686/libc.so.6
#34 0x40360c5f in __libc_start_main () from /lib/i686/libc.so.6

I've no idea how all that ssg stuff works so someone else will have to
fix it.

> -Cleanup main menu (No multiplayer button, if there is no multiplayer

There is split screen multiplayer, and other than the aforementioned
segfaulting plus the fact the framerate drops low enough to make it
unplayable, it works. I should make joystick controls configurable and
not just keyboard ones, I'll do it once it's clear other people are also
doing something (as it will be boring).

>  same goes for sound and display settings). A display setting for 
>  resolution and fullscreen would be a good idea though.

Adding in a menu button called "fullscreen" is easy, but as far as I
know when you do something like switch to/from fullscreen you have to
reload all textures, which means someone who knows OpenGL/Plib would
need to do it.

> -Add back buttons to the menus

Someone (I think oaf_thadres) already did this, but then I removed them
as I thought they looked messy and were unnecessary. You can go back in
menus by:

- pressing escape
- pressing the brake keyboard button
- pressing the brake joystick button
- pressing the right mouse button

Still, I've done enough arguing on this list, if someone really wants to
put them back again, go ahead.

> -Add a highscore for timetrial (and eventually single race)
> -Add a score table that is displayed at the end of each race in 
>  championship mode.
> -Add a credits screen
> -Fix bullets and specials (probably remove some bad working ones like
the 
>  magnet, the rockets and speed powerups should be easy to revive)
> -give penality when beaming back to the track. (ie. when pressing d or
>  when you hit a deadly-texture or so). Your car should get beamed back
and 
>  blink or fade in for a second or 2 in which you can't drive.
> 
> These should be all easy tasks to do and are needed for the release to
be 
> at least fun to play IMO.

If someone volunteers to do these things, then yes they would add
greatly to the game and wouldn't be particularly major undertakings. But
someone would still have to volunteer to do them.

        James

On Mon, 11 Oct 2004, James Gregory wrote:

> - Copying and pasting in the old physics+AI code from the pre-GOTM
> Tuxkart, and then just making some minor tweaks to the sensitivity of
> the handling
Well the physics currently in cvs isn't worse than the old physics, so it 
should be okay to keep it IMO. (Maybe some more tweaking with the 
constants could improve it)

> - Either fixing tire tracks or simply removing them
At the moment we should disable them, since tire tracks only happen when 
the car slides, just with the current physics code the car simply doesn't 
slide.

> - Sorting out LOD.
> 
> And actually releasing something?
Yep pushing for a release would be a good idea. I'll have my last exam 
tomorrow and then I should have a little more time to work on this...
There's also other stuff that could easily be worked on:
-Fix splitscreen multiplayer
-Cleanup main menu (No multiplayer button, if there is no multiplayer,
 same goes for sound and display settings). A display setting for 
 resolution and fullscreen would be a good idea though.
-Add back buttons to the menus
-Add a highscore for timetrial (and eventually single race)
-Add a score table that is displayed at the end of each race in 
 championship mode.
-Add a credits screen
-Fix bullets and specials (probably remove some bad working ones like the 
 magnet, the rockets and speed powerups should be easy to revive)
-give penality when beaming back to the track. (ie. when pressing d or 
 when you hit a deadly-texture or so). Your car should get beamed back and 
 blink or fade in for a second or 2 in which you can't drive.

These should be all easy tasks to do and are needed for the release to be 
at least fun to play IMO.

Greetings,
	Matze

- Copying and pasting in the old physics+AI code from the pre-GOTM
Tuxkart, and then just making some minor tweaks to the sensitivity of
the handling
- Either fixing tire tracks or simply removing them
- Sorting out LOD.

And actually releasing something?

	James

On Tue, 28 Sep 2004, Joel Davis wrote:

> Hello.. I saw the gotm mention of tuxkart (a little
> late, I guess) and wanted to try and contribute. I'm a
> programmer but I want to get a little more practice
> doing level design and level building so I was
> thinking of trying to build a "halloween" themed track
> (before halloween).
> 
> I had some questions, first a political one: Is there
> any objections to using non-free software to create
> content as long as the content is given to the tuxkart
> project? There aren't any legal issues, but people
> might have concerns about the open-source purity of
> the project, and I'd respect that. All of the links
> and tutorials mention only open source tools. (I'll
> contibute any exporters I write in the process). If
> people have a problem with the use of proprietary
> tools, I'll find another way to contribute.
> 
You can use non-free tools too. In fact all old tuxkart tracks have been 
created with ac3d which is no free app. Although there are some good 
reasons why we prefer free tools:

- Ideological: After all we're writing free software and wanna push
  usage of free software
- Practical: If others want to change/improve/work on your models they 
  are forced to buy a commercial app. Often this makes it impossible for 
  people to contribute.

> Next, some technical questions:
> - How does the engine handle visibility? Should I
> break the track into chunks that the engine can cull,
> or will it do that when it loads? How big should each
> chunk be for the engine to be happy?
Yes we need chunks, I'm not really sure what chunk size is optimal.

> - instancing?
See file format docu at homepage

> - does the ac3d format support per-vertex color (aka
> prelight?)
I think yes, eventually consult google or the source code of the ac3d 
loader in plib.

> - texture budget? And is the 256 res. limit still in
> effect now that no one uses voodoo cards?
I think textures can be any color depth and png now.

> - how does the engine decide what to use for
> collision? can we mark geometry to not-collide? what
> about collision-only geometry? should I just use
> regular geometry with a 100% transparent map?
You can set flags on a per-texture basis. (Though there isn't even a 
 NoCollision flag yet I think but it should be easy to add).

> 
> I'm sure I'll have more questions once I start
> modeling, and I can always dig through the code to
> answer them, but I thought I'd ask the experts, and
> introduce myself.
Welcome Joe

Greetings,
	Matze

Hello.. I saw the gotm mention of tuxkart (a little
late, I guess) and wanted to try and contribute. I'm a
programmer but I want to get a little more practice
doing level design and level building so I was
thinking of trying to build a "halloween" themed track
(before halloween).

I had some questions, first a political one: Is there
any objections to using non-free software to create
content as long as the content is given to the tuxkart
project? There aren't any legal issues, but people
might have concerns about the open-source purity of
the project, and I'd respect that. All of the links
and tutorials mention only open source tools. (I'll
contibute any exporters I write in the process). If
people have a problem with the use of proprietary
tools, I'll find another way to contribute.

Next, some technical questions:
- How does the engine handle visibility? Should I
break the track into chunks that the engine can cull,
or will it do that when it loads? How big should each
chunk be for the engine to be happy?
- instancing?
- does the ac3d format support per-vertex color (aka
prelight?)
- texture budget? And is the 256 res. limit still in
effect now that no one uses voodoo cards?
- how does the engine decide what to use for
collision? can we mark geometry to not-collide? what
about collision-only geometry? should I just use
regular geometry with a 100% transparent map?

I'm sure I'll have more questions once I start
modeling, and I can always dig through the code to
answer them, but I thought I'd ask the experts, and
introduce myself.

Thanks!
Joel

On Wed, 2004-09-08 at 12:18 +0200, Charles Bigcat wrote:
> I can provide original loopable background music for all tracks in Ogg 
> format. It'll be more
> along the classical lines (say, like the music from Diddy Kong Racing).

Please do!  I see no reason why good submissions wouldn't be immediately
accepted and put into the game.
-- 
- Charlie

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

2000	Jan	Feb	Mar	Apr (2)	May	Jun (8)	Jul (46)	Aug (1)	Sep (1)	Oct	Nov (1)	Dec
2001	Jan (2)	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2002	Jan (1)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2004	Jan	Feb	Mar	Apr	May	Jun (192)	Jul (199)	Aug (137)	Sep (59)	Oct (28)	Nov	Dec
2005	Jan	Feb	Mar	Apr (12)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan (1)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar (2)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

tuxkart-devel Mailing List for Tux Kart (Page 2)

tuxkart-devel — TuxKart Developers.