Thread: [Tuxracer-devel] too many Particles and libtcl8.x
Status: Beta
Brought to you by:
jfpatry
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/ | ------------------------------------------------------------------------+ |
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: 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 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: 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-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-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...@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: 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: 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-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 |