tuxracer-devel Mailing List for Tux Racer (Page 7)
Status: Beta
Brought to you by:
jfpatry
You can subscribe to this list here.
2000 |
Jan
|
Feb
(7) |
Mar
(90) |
Apr
(39) |
May
(9) |
Jun
(2) |
Jul
(3) |
Aug
(10) |
Sep
|
Oct
(8) |
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Steve B. <sjb...@ai...> - 2000-03-02 04:37:04
|
I decided to have a go at designing a level - it's pretty easy but I have a couple of questions: 1) I change the 'tux_start_pt' to the beginning of my course - but what happens is that Tux appears somewhere completely *wrong*, lies down - and then teleports to the position I told him to start at. I'm guessing that I need to edit the keyframe animation at the bottom of the tcl file - but that looks like being a real pain to do. Would it be possible for that set of keyframes to work in a coordinate system that's relative to 'tux_start_pt' - it would make it much easier to steal the initial animation from another level. 2) It's *REALLY* hard to avoid getting small hollows in the track that Tux can get stuck in. If the track is more or less straight (as with all the existing levels) - that's OK - you just crank up the overall track slope and he'll slide out of the more subtle "traps". However, I'm trying to build a really winding 'S' shaped track - and increasing the tilt of the track doesn't help because you just get even more stuck in the east/west sections of the 'S' curve. There really needs to be a key on the keyboard to make Tux either paddle his arms to get a little thrust so he can go S-L-O-W-L-Y uphill - or he needs to be able to stand up and walk out! 3) At the bottom end of the track, the large 'snow' polygon at the end of the track comes out way too high - so we disappear under the snow when there is still a LOT of track left - eventually the camera pops under that polygon also - and you can see clearly to the end of the track - where it ends abruptly with blue sky. 4) With the friction values stolen from level 1, Tux tends to get 'stuck' on the edges of rock patches - he slides onto the rock, flips around 180 degrees - then slowly moves back onto snow - flips back and so on - sometimes forever. Reducing the friction on the rocks seems to help this a lot - but there are still some strangenesses. 5) Are you culling the scene polygons to the view frustum? I think the speed of the game depends pretty critically on the overall size of the track. 6) It would be cool to be able to set the fog range - so that in some levels things would 'emerge' from the mist unexpectedly. That should be a pretty low cost feature. 7) It would be nice to put those large background.rgb files into the 'common' area...I don't think many people will be painting their own - so it would be better to be able to share them nicely. Anyway, I have a track of sorts done - where would you like me to post it? -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Steve B. <sjb...@ai...> - 2000-03-02 04:03:19
|
Jasmin Patry wrote: > Hmm. First, try setting fullscreen back to 0. The fullscreen option is > perhaps a bit misleading; all it does is activate game mode in GLUT, and > as far as I can tell all that does under Linux is make the window the > same size as the screen... Yep - I was just looking at the code - I think you're right. > Well, I remember getting it to work on a Voodoo-2 without any special > hacks -- I think I just set the resolution and the environment variables > and it worked fine. That was a while ago, though, and Tux Racer has > changed a fair bit since then. Two things you DEFINITELY need are: 1) Make sure that the window comes up nailed to the screen - so you don't have to give it an initial position with the mouse. 2) Every frame or so do a: glutWarpPointer(width/2,height/2); - this prevents the mouse pointer from being accidentally moved outside the underlying X window - resulting in a loss of keyboard focus - and a serious problem to recover from! > BTW: Enjoy your vacation! Thanks! -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Jasmin P. <jf...@mu...> - 2000-03-02 03:18:13
|
On Wed, 1 Mar 2000, Steve Baker wrote: > I tried to play tuxracer on a Voodoo-1 (it would be the same on a Voodoo-2). > > First, since these cards can ONLY run in fullscreen mode, it's necessary > to set ~/.tuxracer so it has 'set fullscreen 1' - but when I do that, the > image comes out showing me only the bottom-left corner of the game screen > (that's because my X-window screen res is 1024x768 but the Voodoo card can > only render 640x480. Hmm. First, try setting fullscreen back to 0. The fullscreen option is perhaps a bit misleading; all it does is activate game mode in GLUT, and as far as I can tell all that does under Linux is make the window the same size as the screen... > When I try to fix that by setting the resolution explicitly in ~/.tuxracer, > it ignores it - and even overwrites the settings in the file with 1024x768! ... which explains this, I think. Remembering back to my pre-DRI days -- I did large chunk of Tux Racer development with (Voodoo3) fullscreen rendering, and that was before the "fullscreen" option -- the Voodoo's fullscreen 3D mode would kick in whenever I started Tux Racer at a resolution that matched one of the configured resolutions in my XF86Config file (with MESA_GLX_FX set to "fullscreen", etc.). So I'd hope that fullscreen 3D would kick in if you start Tux Racer at 640x480, but maybe that's wishful thinking. > I think the problem here is that those ancient Voodoo cards simply cannot > be made to work without special code entered just for them. > > It'll take a special config option to make them work - and some nasty hacks > to the code. I'll see if I have time to make them...but unfortunately, I'm > off on vacation for 2 weeks starting Friday - so it may not get done all that > soon. Well, I remember getting it to work on a Voodoo-2 without any special hacks -- I think I just set the resolution and the environment variables and it worked fine. That was a while ago, though, and Tux Racer has changed a fair bit since then. BTW: Enjoy your vacation! Cheers, Jasmin |
From: Jasmin P. <jf...@mu...> - 2000-03-02 02:46:35
|
On Wed, 1 Mar 2000, Steve Baker wrote: > Would it be possible to change the setup of this list so that the > 'Replyto' field sends replies to the entire list instead of to the > author of the message? Yeah, this was really starting to bug me. :-) Should be fixed now. Cheers, Jasmin |
From: Jasmin P. <jf...@mu...> - 2000-03-02 02:23:45
|
On Wed, 1 Mar 2000, Steve Baker wrote: > Are there plans to allow arbitary polygonal objects to be added into > tracks? It would be nice to be able to build tunnels, different > kinds of trees, snowman, that kind of thing. It sure would. Yes, I'd definitely like to support things like this. The details of how to go about doing this are still fuzzy in my mind, though, so it's probably not something that's going to happen in the very near future. Well, let's see. Multiple tree types per level is easy. Polygonal objects would be fairly easy if restricted to convex polyhedra (I'd need to find out how to load model files, like .obj or .3ds files, but I don't think that's very hard either). The collision detection code would need to be rewritten to support non-convex objects; however, I think we may be convering this soon in my computational geometry course. So all of this may happen sooner that I initially thought. :-) > Oh - and BTW I have now subscribed to tuxracer-devel so there is no > need to forward messages to me explicitly. Ok, great! Cheers, Jasmin |
From: Steve B. <sjb...@ai...> - 2000-03-01 23:16:07
|
I tried to play tuxracer on a Voodoo-1 (it would be the same on a Voodoo-2). First, since these cards can ONLY run in fullscreen mode, it's necessary to set ~/.tuxracer so it has 'set fullscreen 1' - but when I do that, the image comes out showing me only the bottom-left corner of the game screen (that's because my X-window screen res is 1024x768 but the Voodoo card can only render 640x480. When I try to fix that by setting the resolution explicitly in ~/.tuxracer, it ignores it - and even overwrites the settings in the file with 1024x768! I think the problem here is that those ancient Voodoo cards simply cannot be made to work without special code entered just for them. It'll take a special config option to make them work - and some nasty hacks to the code. I'll see if I have time to make them...but unfortunately, I'm off on vacation for 2 weeks starting Friday - so it may not get done all that soon. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Steve B. <sjb...@ai...> - 2000-03-01 21:41:20
|
Would it be possible to change the setup of this list so that the 'Replyto' field sends replies to the entire list instead of to the author of the message? I know sourceforge's mailer can do this because my own sourceforge projects are set up that way. Sourceforge say that they don't recommend that you do this - but that's just their own personal bias coming in. Almost all lists have replyto pointing back to the main list and it's VERY confusing when there is an odd one that doesn't. Thanks. Steve -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Steve B. <sjb...@ai...> - 2000-03-01 21:33:44
|
Ingo Ruhnke wrote: > BTW. I am working on a little track, I'll mail it to you, if I am > done. Cool! Are there plans to allow arbitary polygonal objects to be added into tracks? It would be nice to be able to build tunnels, different kinds of trees, snowman, that kind of thing. Oh - and BTW I have now subscribed to tuxracer-devel so there is no need to forward messages to me explicitly. -- Steve Baker http://web2.airmail.net/sjbaker1 sjb...@ai... (home) http://www.woodsoup.org/~sbaker sj...@ht... (work) |
From: Jasmin P. <jf...@mu...> - 2000-03-01 15:59:15
|
On 1 Mar 2000, Ingo Ruhnke wrote: > Your patch does the trick, thanks. The game works perfectly now! Glad to hear it! > BTW. I am working on a little track, I'll mail it to you, if I am > done. Great! Looking forward to seeing it. There are a few things I want to change wrt to the course stuff: * Add a Tcl callback so that the course author's name, and possibly a course description can be displayed on the start screen * Change the course directory naming in the data dir; currently, course directory names are numbers, but this should be changed so that they reflect the course name (that way a new course can be dropped in without having to worry about number conflicts). This probably necessitates a course index file... or perhaps course directories could be identified by the presence of the course.tcl file (something is required to tell the program that the "common" directory isn't a course). * Lighting should be configurable on a per-course basis. I'm sure I've forgotten a few things too. Additional ideas are welcome. Cheers, Jasmin |
From: Jasmin P. <jf...@ho...> - 2000-03-01 15:48:21
|
I've released version 0.10.1, a bug fix release. This fixes a particularly nasty bug in the steering code, which resulted in far too many particles being generated. The course lighting has also been adjusted. You can download it from http://tuxracer.sourceforge.net . Thanks! Cheers, Jasmin |
From: Ingo R. <gr...@gm...> - 2000-03-01 15:22:15
|
Jasmin Patry <jf...@cg...> writes: > Spot on. Thanks! I've tracked it down to a problem with the automatic > centering of steering. This bug was actually framerate dependent; it > would only be triggered by framerates below 18 Hz. I almost always get > over 20 Hz so that explains why I only saw this happen once. I only get here something around 10Hz, thats explains why the problem always occurred. >> That didn't help. Tux gets totally out of controll if I press J or L, >> looks like the problem is not the particle system, but instead that >> there is something wrong with the controls. > > Yup, that's consistent with the bug I found. Please try the attached > patch and let me know if things are better. Your patch does the trick, thanks. The game works perfectly now! BTW. I am working on a little track, I'll mail it to you, if I am done. -- ICQ: 59461927 http://pingus.seul.org | Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ | ------------------------------------------------------------------------+ |
From: Jasmin P. <jf...@mu...> - 2000-03-01 06:25:55
|
On Tue, 29 Feb 2000, Michael Dale Long wrote: > Here's a very simple patch that keeps the dark areas on the map from > being too dark for a snowfield, without washing out the color on Tux. > Enjoy. Ok, that part of the code definitely needed some cleaning up. :-) There was some dead code in there that's been removed, and I adjusted the course lighting close to your settings, Michael. Patch against 0.10 attached. Thanks, Jasmin |
From: Jasmin P. <jf...@mu...> - 2000-03-01 03:54:53
|
On 29 Feb 2000, Ingo Ruhnke wrote: > There is no core file generated. So I played a bit around with gdb: [snip] > | #0 create_new_particles (loc={x = 0.67505081281655532, > | y = -20.186827572125033, z = -50.121188293065998}, vel={x = 0, y = 1, > | z = 0}, num=186591) at part_sys.c:66 > | ^^^^^^ <-------------------- This looks far to big [snip] > > Looks like plyr->control.turn_fact is the cause for this: > > ,---- > | (gdb) print generate_particles::plyr->control.turn_fact > | $5 = 48711.292061943917 > `---- Spot on. Thanks! I've tracked it down to a problem with the automatic centering of steering. This bug was actually framerate dependent; it would only be triggered by framerates below 18 Hz. I almost always get over 20 Hz so that explains why I only saw this happen once. > > By the way, if you want to suppress particle generation altogether, > > simply comment out the call to generate_particles() in phys_sim.c. > > That didn't help. Tux gets totally out of controll if I press J or L, > looks like the problem is not the particle system, but instead that > there is something wrong with the controls. Yup, that's consistent with the bug I found. Please try the attached patch and let me know if things are better. Thanks, Jasmin *** racing.c.0.10 Tue Feb 29 22:15:08 2000 --- racing.c Tue Feb 29 22:37:27 2000 *************** *** 31,36 **** --- 31,40 ---- #include "tux_shadow.h" #include "phys_sim.h" #include "part_sys.h" + #include "screenshot.h" + + /* Time constant for automatic steering centering (s) */ + #define TURN_DECAY_TIME_CONSTANT 0.2 static bool_t right_turn; static bool_t left_turn; *************** *** 76,82 **** increment_turn_fact( plyr, ( left_turn ? -1 : 1 ) * 0.2 * time_step / 0.05 ); } else { ! plyr->control.turn_fact *= 0.9 * time_step / 0.05; } update_player_pos( plyr, time_step ); --- 80,91 ---- increment_turn_fact( plyr, ( left_turn ? -1 : 1 ) * 0.2 * time_step / 0.05 ); } else { ! /* Automatically centre steering */ ! if ( time_step < TURN_DECAY_TIME_CONSTANT ) { ! plyr->control.turn_fact *= 1.0 - time_step/TURN_DECAY_TIME_CONSTANT; ! } else { ! plyr->control.turn_fact = 0.0; ! } } update_player_pos( plyr, time_step ); |
From: Ingo R. <gr...@gm...> - 2000-02-29 14:11:13
|
Jasmin Patry <jf...@cg...> writes: > To follow up on the particle system bug: > > If you can reliably re-create the problem, Yep, I can reproduce the problem, since it always happens when I press J or L. > could you please apply the attached patch to part_sys.c and send me > the resulting core file? There is no core file generated. So I played a bit around with gdb: ,---- | nstuxracer: Maximum number of particles exceeded. | *** Please help the Tux Racer developers by emailing the core file | *** that has just been created (gzip it first, please) to | *** <jf...@cg...>. Thanks! | | Breakpoint 1, create_new_particles (loc={x = 0.67505081281655532, | y = -20.186827572125033, z = -50.121188293065998}, vel={x = 0, y = 1, | z = 0}, num=186591) at part_sys.c:66 | 66 assert( 0 ); | (gdb) bt | #0 create_new_particles (loc={x = 0.67505081281655532, | y = -20.186827572125033, z = -50.121188293065998}, vel={x = 0, y = 1, | z = 0}, num=186591) at part_sys.c:66 | ^^^^^^ <-------------------- This looks far to big | #1 0x80598e5 in generate_particles (plyr=0x806e4bc, | dtime=0.0012768565664670987, pos={x = 0.50005081281655528, | y = -20.186827572125033, z = -50.121188293065998}, | speed=78.311284378030109) at phys_sim.c:754 `---- Looks like plyr->control.turn_fact is the cause for this: ,---- | (gdb) print generate_particles::plyr->control.turn_fact | $5 = 48711.292061943917 `---- > Please also specify your compiler version (I'm assuming I'll need to use > the same version to use your core file, or no? I'm new to distributed > development. :-). I'm using gcc 2.95.2, but AFAIK you need the same tuxracer binary as I used to generate the core file. > By the way, if you want to suppress particle generation altogether, > simply comment out the call to generate_particles() in phys_sim.c. That didn't help. Tux gets totally out of controll if I press J or L, looks like the problem is not the particle system, but instead that there is something wrong with the controls. -- ICQ: 59461927 http://pingus.seul.org | Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ | ------------------------------------------------------------------------+ |
From: Jasmin P. <jf...@mu...> - 2000-02-29 11:50:56
|
On Tue, 29 Feb 2000, Michael Dale Long wrote: > First, I'd just like to say this is very cool, keep up the good work. Thanks very much! > Here's a very simple patch that keeps the dark areas on the map from > being too dark for a snowfield, without washing out the color on Tux. > Enjoy. Great! I'll have a look at it this everning... (Note to self: don't release an open-source game during midterms. ;-) Cheers, Jasmin |
From: Michael D. L. <ml...@lo...> - 2000-02-29 05:51:02
|
First, I'd just like to say this is very cool, keep up the good work. Here's a very simple patch that keeps the dark areas on the map from being too dark for a snowfield, without washing out the color on Tux. Enjoy. -Michael |
From: Jasmin P. <jf...@mu...> - 2000-02-29 04:23:49
|
On Mon, 28 Feb 2000, Jasmin Patry wrote: > > To follow up on the particle system bug: [snip] > *** part_sys.c.0.10 Mon Feb 28 22:12:40 2000 > --- part_sys.c Mon Feb 28 22:32:56 2000 [snip] > + if ( num_particles > MAX_PARTICLES ) { Argh, this should be changed to + if ( num_particles + num > MAX_PARTICLES ) { so that we catch it on the call that it occurs, not on the next call. Hopefully this will be my last patch on the patch. :-) Cheers, Jasmin |
From: Jasmin P. <jf...@mu...> - 2000-02-29 03:52:21
|
To follow up on the particle system bug: If you can reliably re-create the problem, could you please apply the attached patch to part_sys.c and send me the resulting core file? Please also specify your compiler version (I'm assuming I'll need to use the same version to use your core file, or no? I'm new to distributed development. :-). By the way, if you want to suppress particle generation altogether, simply comment out the call to generate_particles() in phys_sim.c. Thanks, Jasmin *** part_sys.c.0.10 Mon Feb 28 22:12:40 2000 --- part_sys.c Mon Feb 28 22:32:56 2000 *************** *** 23,28 **** --- 23,32 ---- #include "phys_sim.h" #include "gl_util.h" + /* This constant is here as part of a debugging check to prevent an infinite + number of particles from being created */ + #define MAX_PARTICLES 100000 + #define START_RADIUS 0.1 #define PART_SIZE 0.07 #define PART_SPEED 1.3 *************** *** 40,45 **** --- 44,50 ---- static colour_t partColour = { 0.69, 0.72, 0.906 }; static Particle* head = NULL; + static int num_particles = 0; scalar_t frand() { *************** *** 51,59 **** --- 56,82 ---- Particle *newp; int i; + /* Debug check to track down infinite particle bug */ + if ( num_particles > MAX_PARTICLES ) { + fprintf( stderr, + "tuxracer: Maximum number of particles exceeded.\n" + "*** Please help the Tux Racer developers by emailing the core file \n" + "*** that has just been created (gzip it first, please) to \n" + "*** <jf...@cg...>. Thanks!\n"); + assert( 0 ); + } + for (i=0; i<num; i++) { newp = (Particle*)malloc( sizeof( Particle) ); + + if ( newp == NULL ) { + fprintf( stderr, "tuxracer: Out of memory.\n" ); + exit( -1 ); + } + + num_particles += 1; + newp->next = head; head = newp; *************** *** 108,113 **** --- 131,137 ---- q = *p; *p = q->next; free(q); + num_particles -= 1; continue; } *************** *** 150,153 **** --- 174,178 ---- free(q); } head = NULL; + num_particles = 0; } |
From: Jasmin P. <jf...@mu...> - 2000-02-29 02:54:34
|
On 29 Feb 2000, Ingo Ruhnke wrote: > just played a bit around with TuxRacer, it looks great for an initial > release! Thanks! > Just some problems I had: > > If I stear left or right, Tux starts to throw particles, but far to > many, so the game slows down and is after some seconds completly > frozen. Looks there is a problem with limiting the number of particles > that gets thrown, so TuxRacer starts to completly eat up all memory > and freeze. I'm glad you were able to recreate this problem (sorry for the freeze-up, though!). I've only had it happen to me once in many hours of play; every other time the "correct" number of particles were generated. Is it consistent on your machine? If so, could you give me more details about your configuration? > Another simple problem which I experienced at build time, ./configure > looks for libtcl, but on Debian 2.3 systems the tcl libs are called > libtcl7.6.so, libtcl8.0.so and libtcl8.2.so so the configure script > cannot find them. Changing TCL_LIB_NAME to one of the above names > solved the problem. I assume you mean the --with-tcl-lib-name configure option. The configure script should probably be changed to look for libtcl8.0.so (at least) in addition to libtcl.so. Thanks again for the feedback, Jasmin |
From: Ingo R. <gr...@gm...> - 2000-02-29 02:39:34
|
Hi, just played a bit around with TuxRacer, it looks great for an initial release! Just some problems I had: If I stear left or right, Tux starts to throw particles, but far to many, so the game slows down and is after some seconds completly frozen. Looks there is a problem with limiting the number of particles that gets thrown, so TuxRacer starts to completly eat up all memory and freeze. Another simple problem which I experienced at build time, ./configure looks for libtcl, but on Debian 2.3 systems the tcl libs are called libtcl7.6.so, libtcl8.0.so and libtcl8.2.so so the configure script cannot find them. Changing TCL_LIB_NAME to one of the above names solved the problem. -- ICQ: 59461927 http://pingus.seul.org | Ingo Ruhnke <gr...@gm...> http://home.pages.de/~grumbel/ | ------------------------------------------------------------------------+ |