tuxracer-devel Mailing List for Tux Racer (Page 6)

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

I introduced a silly bug into 0.11, so I've released Tux Racer 0.11.1.
If Tux Racer 0.11 coredumped on you, this should fix it. 

Thanks,
Jasmin

On Mon, 6 Mar 2000, Sten Eriksson wrote:

> With "tuxracer-0.11.tar.gz" I get a Segmentation fault.
> Below is a patch that fixes this

Thanks very much.  It figures that the very last change I did before 0.11 is
the culprit. :-)  I'll have 0.11.1 out in a few minutes.

Cheers,
Jasmin

With "tuxracer-0.11.tar.gz" I get a Segmentation fault.
Below is a patch that fixes this
-- cut here --
*** string_util.c       Mon Mar  6 10:10:36 2000
--- string_util.c.org   Fri Feb 25 02:56:59 2000
***************
*** 34,45 ****
!     if ((s1 != NULL) && (s2 != NULL)) {
!       s1c = string_copy( s1 );
!       s2c = string_copy( s2 );
!       string_to_lower( s1c );
!       string_to_lower( s2c );
!       retval = strcmp( s1c, s2c );
!       free( s1c );
!       free( s2c );
!       return retval;
!     } else {
!       return (s1 == s2);
!     }
--- 34,41 ----
!     s1c = string_copy( s1 );
!     s2c = string_copy( s2 );
!     string_to_lower( s1c );
!     string_to_lower( s2c );
!     retval = strcmp( s1c, s2c );
!     free( s1c );
!     free( s2c );
!     return retval;
-- cut here --

-----------------------------------------------------------------
Sten Eriksson            ! E-mail:    ste...@ud...
UDAC AB / Datorhotellet  ! Tel, work: +46 18 471 78 20
Box 174                  ! Tel, mob:  +46 70 542 47 03
SE-751 04 Uppsala        ! Tel, fax:  +46 18 51 66 00
SWEDEN                   !
-----------------------------------------------------------------

I've released Tux Racer 0.11. This release introduces several changes
for the benefit of course designers; they can now customize lighting,
fog, and particle colour to their liking. 

The biggest change to gameplay is that courses can now be played in
"mirrored" mode, for added variety. 

Two new user-contributed courses are also included.

All of the configuration variables in ~/.tuxracer are now documented in
the README file.

Several other changes and bug fixes were performed; please see the
ChangeLog.

Enjoy!

Jasmin

On 6 Mar 2000, Ingo Ruhnke wrote:

> > I noticed while playing that Tux was really bouncing around in spots.
> > I decided to tweak the physics code a bit -- in particular, Tux's
> > damping coefficients, and some of the parameters controlling the ODE
> > solver. I'm attaching a patch against 0.10.1; can anybody who has time
> > please try it out and let me know if you like the result?
> 
> I'll try to have a look at that tomorrow, I need some sleep now. %-)

:-) That patch made it into 0.11, so you might just want to look at that
instead.

Cheers,
Jasmin

On 6 Mar 2000, Ingo Ruhnke wrote:

> "Ingo's Speedway" sounds nice :-), have at the moment no idea for a
> better name, so lets use it. 

Ok, I just released it in the 0.11 release.

Cheers,
Jasmin

On 6 Mar 2000, Ingo Ruhnke wrote:

> I just finished a little script-fu script. It takes an multi layer
> image and saves it as a set of rgb images, using the layer names as
> filename (elev, trees, terrain).
> So a level can be created as an .xcf file, which makes it much easier
> to maintain the level, than having three different files.

That's great! I'd been meaning to write something like that.  I'll put it on
the site tomorrow; I'm sure people will find it very helpful.

> To install the script, simply copy it to: ~/.gimp-1.1/scripts/ and
> restart Gimp.

BTW, I also created a version that works with 1.0.

Thanks!
Jasmin

Jasmin Patry <jf...@mu...> writes:

>> http://pingus.seul.org/~grumbel/5.tar.gz
> 
> Wow!! I love it!

Thanks.

> * It's easy in a few spots to avoid the paths and canyons that you've
>   created; for example, I find it faster to climb on the large flat
>   areas above the rest of the track (about halfway down).  Sticking trees/rocks
>   up there would discourage that.

Jupp, didn't notice that before. I placed some new trees to stopp that.

>   The curvy icy bridge thing near the beginning is also easy to
>   avoid by hitting it dead on and jumping it -- though that's kind
>   of fun. :-)

That wasn't intentional when I created it, but its makes fun and gives
the level a lot more speed, I think we leave it that way.

> * A few trees are very close to the edge of the course on the right hand
>   side, and because of a bug in the heightmap interpolation code (I
>   think), they're suspended in mid air.  You might want to move them in
>   a bit until I get that fixed.

Ok, I fix that.

> * The paths in the course.tcl file should be relative; the file is
>   interpreted with the CWD in the course's directory.

Yep, correct. I only used that to have the levels in my home dir
(symlink to /usr/...), I didn't noticed the ~/.tuxracer file, where I
can configure that. 

> I'd like to include it in tuxracer-data-0.10.1; is that OK?

Sure.

> I noticed while playing that Tux was really bouncing around in spots.
> I decided to tweak the physics code a bit -- in particular, Tux's
> damping coefficients, and some of the parameters controlling the ODE
> solver. I'm attaching a patch against 0.10.1; can anybody who has time
> please try it out and let me know if you like the result?

I'll try to have a look at that tomorrow, I need some sleep now. %-)

-- 
ICQ: 59461927                                    http://pingus.seul.org | 
Ingo Ruhnke <gr...@gm...>             http://home.pages.de/~grumbel/ |
------------------------------------------------------------------------+

Jasmin Patry <jf...@mu...> writes:

>> http://pingus.seul.org/~grumbel/5.tar.gz
> 
> I'd like to get 0.10.2 releases of tuxracer and tuxracer-data out today.
> I've added the ability to specify the name and author of the course,
> which is displayed on the start screen. 
> Can you suggest a name for your course?  The best I can come up with
> is "Ingo's Speedway". :-)

"Ingo's Speedway" sounds nice :-), have at the moment no idea for a
better name, so lets use it. 

-- 
ICQ: 59461927                                    http://pingus.seul.org | 
Ingo Ruhnke <gr...@gm...>             http://home.pages.de/~grumbel/ |
------------------------------------------------------------------------+

On 2 Mar 2000, Ingo Ruhnke wrote:

> Ok, my first level is more or less ready. Its still needs some fixing,
> but should be enough to have some fun. Its available at:
> 
> http://pingus.seul.org/~grumbel/5.tar.gz

I'd like to get 0.10.2 releases of tuxracer and tuxracer-data out today.
I've added the ability to specify the name and author of the course,
which is displayed on the start screen.  Can you suggest a name for your
course?  The best I can come up with is "Ingo's Speedway". :-)

Cheers,
Jasmin

On Fri, 3 Mar 2000, Steve Baker wrote:

> Jasmin Patry wrote:
> > 
> > Ah, very cool.  I hope to check out PLIB over the weekend -- I'd
> > already been meaning to look at it for its text capabilities.
> 
> ...and GUI, sound and music :-)

:-)  Since the game was written as a school project, using a third-party
library wasn't possible.  I'm encouraged by your description of how SSG
works -- it doesn't sound like it will be hard to use it to insert
additional objects into the track.  

Do you foresee any problems caused by the fact that PLIB/SSG is C++ and
Tux Racer is written in C?  I'll have to include at least some C++, I
guess, for the classes in SSG that I subclass, but I should be able to
abstract the functionality that I use SSG for behind a C interface.

> > I take that back -- convex polyhedra aren't really necessary in a game
> > context.  I was thinking of a general collision detection algorithm --
> > to be able to use the intersection-of-halfspaces approach to handle
> > the case in which one object is completed contained inside the other,
> > the objects must be convex.  In a game where the time steps small, an
> > object will almost surely intersect the boundary of the other object
> > first, so the approach you describe below is fine.
> 
> Yes - it's also possible to intersect a bunch of lines that start at the
> position of tux at the beginning of the frame and end at the position
> he hopes to be at at the end of the frame.  Using a set of lines that
> outline his profile, you could even use my approach to detect high
> time step motion.
> 
> In my Tux game, I did get problems with a fast moving Tux starting the
> frame completely on one side of a polygon - and ending it completely
> on the other.  To fix that, I intersect a bunch of slightly overlapping
> Tux-sized spheres at intervals along his motion.

Right, I had problems with this too. The correct way to do it in Tux Racer
would be to stretch out each sphere into a cylinder with hemispherical
ends, but instead I basically use the approach you use: the set of
physics equations in Tux Racer is solved using a variable time-step ODE
solver, which takes many steps in general for each rendered frame.

> This isn't 'perfect' in a college-course kind of a way - but it's pretty
> good for things like video games where people are quite tolerant of
> small problems.

Yes.

> In PLIB/SSG, a "material" is represented by a class derived from 'ssgState'
> (which represents the OpenGL state required to render polygons with that
> material).  Currently, ssgState is an abstract base class with the only
> commonly used concrete derivced class being ssgSimpleState.
> 
> When you do an intersect test, you get back a pointer to the ssgLeaf node
> that you collided with. There is API for ssgLeaf to fetch it's ssgState -
> if that's not enough, you can attach a user-data structure to
> ssgState\which could contain stuff like your friction coefficient.
> 
> In my Tux game, it contains friction (I have slippery ice too) - and
> also things like temperature (Tux gets hot if he stands too long near
> to hot lava - and has to walk into a nice cold refrigerator to cool
> down).  I also have a 'lethality' field so that the mouth polygons of
> the Killer Whale can marked as being basically fatal for small
> Penguins.

Yup, that sounds great.

> > My collision detection is a bit more complicated; I check for
> > collisions with each part of Tux's body.  Instead of checking each
> > triangle that makes up Tux, though -- that would be horribly slow -- I
> > transform the object I'm testing down the tree structure representing
> > Tux.  Each leaf of the tree is a unit sphere, centered at the origin,
> > and it's easy to check for a collision between this sphere and an
> > arbitrary polyhedron.  This is reasonably fast currently because the
> > polyhedrons are octahedrons (the trees).
> 
> Wow!  That's pretty fancy.

It gives pretty accurate collisions.  The idea is just an extension
of the ray intersection code for a ray tracer I wrote -- as you traverse
the hierarchical model, you need to transform the ray using the inverse
of the transforms stored in each node, and then do the intersection in
model space.  

For testing collisions with the SSG objects, I might instead add
bounding (world-space) spheres to the Tux model, and then perform
collision tests with each of these spheres.  That should give reasonably
accurate collisions.  (Or can SSG do the intersection tests with
arbitrary ellipsoids?)

> > P.S. Any reason why this was taken off-list, or was that unintentional?
> 
> It was unintentional - I thought I just hit reply...weird.

Ok, taking it back to the list...

Cheers,
Jasmin

On Fri, 3 Mar 2000, Steve Baker wrote:

> Jasmin Patry wrote:
> 
> > End your track at a grey value of 50% to avoid this.
> 
> Wouldn't it be better to end at black? ...Hmmm - perhaps a settable
> end-height is needed.  Ultimately, you'll probably want to draw a
> 'finish line' or something so you can see where to aim for.  I'd
> like to be able to set that to be someplace inside the course itself
> and do away with the big snow polygon at the bottom altogether.

50% was chosen for maximum flexibility; if courses were supposed to end
at black then it would be impossible to have a chasm immediately before
the end of the course (sort of like the ones at the end of Ingo's level).
It wouldn't be hard to make that settable, though.

Cheers,
Jasmin

On Fri, 3 Mar 2000, Steffen Sobiech wrote:

> Hi there!

Hi!

> I put together a binary version of Tux Racer with
> a GUI Installer (kinst). It will install Tux Racer on
> systems equipped with KDE and automatically
> register it to the K-Menu. Additionally, it can
> be uninstalled with kpackage when KISS is
> installed.

Sounds great! I should warn you that Tux Racer is still very much in
flux, so that binary versions may not stay current for very long.
That's why I haven't bothered to build rpms or debs, yet.

> As I don't want to flood this list with the 1MB
> file: where can I post it to someone who will
> test my stuff?

Please send it directly to my account (jf...@cg...), and
I'll put it up on SourceForge somewhere where people can download it.
I have KDE on my machine so I'll test it too.

Thanks,
Jasmin

Hi there!

I put together a binary version of Tux Racer with
a GUI Installer (kinst). It will install Tux Racer on
systems equipped with KDE and automatically
register it to the K-Menu. Additionally, it can
be uninstalled with kpackage when KISS is
installed.

As I don't want to flood this list with the 1MB
file: where can I post it to someone who will
test my stuff?

--
-- 
Steffen Sobiech
email: sso...@ci...
email: ss...@gm...
ICQ : 18765400
-- 

Jasmin Patry wrote:
> 
> In case any of you are wondering: a week ago I sent one of the
> SourceForge admins my existing CVS repository for incorporation into SF
> after being told that doing that was "not a problem".  I've sent a
> couple of follow-up emails to find out what the status is, but I haven't
> gotten a response.  Hopefully it will happen soon.

If you want to keep all the old history stuff, I guess you may have
to get someone at SourceForge to do it - but those guys are pretty
busy (SourceForge has *EXPLODED* in popularity).

If you can live without all your old history - it's easy to just
follow the information Joel Utting wrote on setting up your CVS
stuff.  That's somewhere in the SourceForge documentation.  I set
up PLIB's CVS in about 10 minutes flat.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Jasmin Patry wrote:

> > 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.
> 
> End your track at a grey value of 50% to avoid this.

Wouldn't it be better to end at black? ...Hmmm - perhaps a settable
end-height is needed.  Ultimately, you'll probably want to draw a
'finish line' or something so you can see where to aim for.  I'd
like to be able to set that to be someplace inside the course itself
and do away with the big snow polygon at the bottom altogether.

These are things that need to be decided *soon* before you have
too many levels built to change it.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

In case any of you are wondering: a week ago I sent one of the
SourceForge admins my existing CVS repository for incorporation into SF
after being told that doing that was "not a problem".  I've sent a
couple of follow-up emails to find out what the status is, but I haven't
gotten a response.  Hopefully it will happen soon.

Cheers,
Jasmin

On Thu, 2 Mar 2000, eric kmetz wrote:

> Okay so I just bought this nvidia TNT2 32MB video
> card about a week ago.  Got their glx.so/libGL
> drivers and their X server.  Got quake3 up and
> going but tuxracer basically broke my X.

Thanks for reporting this.

What version of tuxracer are you running (0.10.1 or 0.10)?  It might
also help to know more about your system -- linux distro and version,
processor, etc.

Does the X server crash as soon as tuxracer starts, or does the game run
for a bit first (and if so, at what point does it crash)?  There was a
bug in 0.10 that caused some people's X servers to crash, but only after
a race had started and one of the turning keys was hit; that was fixed
in 0.10.1.

(Is anybody on the list running Tux Racer successfully on a TNT2?)

Cheers,
Jasmin

On 2 Mar 2000, Ingo Ruhnke wrote:

> Ok, my first level is more or less ready. Its still needs some fixing,
> but should be enough to have some fun. Its available at:
> 
> http://pingus.seul.org/~grumbel/5.tar.gz

Wow!! I love it!

A few comments:

* It's easy in a few spots to avoid the paths and canyons that you've
  created; for example, I find it faster to climb on the large flat
  areas above the rest of the track (about halfway down).  Sticking trees/rocks
  up there would discourage that.  The curvy icy bridge thing near the
  beginning is also easy to avoid by hitting it dead on and jumping it --
  though that's kind of fun. :-)

* A few trees are very close to the edge of the course on the right hand
  side, and because of a bug in the heightmap interpolation code (I
  think), they're suspended in mid air.  You might want to move them in
  a bit until I get that fixed.

* The paths in the course.tcl file should be relative; the file is
  interpreted with the CWD in the course's directory.

I'd like to include it in tuxracer-data-0.10.1; is that OK?

I noticed while playing that Tux was really bouncing around in spots.
I decided to tweak the physics code a bit -- in particular, Tux's
damping coefficients, and some of the parameters controlling the ODE
solver.  I'm attaching a patch against 0.10.1; can anybody who has time
please try it out and let me know if you like the result?

Thanks,
Jasmin

On Wed, 1 Mar 2000, Steve Baker wrote:

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

Yes, good idea.

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

I've been meaning on adding the paddling for a while now.  I like the
walking idea -- I'll give that some thought.

I'd also like to build a simple 3D track editor.  I don't think this
would be hard to do, and would make fixing hollows and the like much
easier.

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

End your track at a grey value of 50% to avoid this.

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

This is because of the way turning works.  In calc_net_force() in
phys_sim.c, I rotate the frictional force about the surface normal to
implement steering (CW to turn left, CCW to turn right).  This seemed to
me like a pretty good approximation, and given the Tux is modelled as a
particle for physics purposes (though not for collision detection), I
have to resort to some sort of hack.  But it does result in weirdness on
surfaces with large friction coefficients -- like rock.  

(Tux really should try to avoid sliding on rock -- it does nasty things
to his backside. :-)

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

I only do simple culling: I cull everything 100m or further in front of
Tux, and 20m or further behind him.  I also do some very simple LOD with
the trees.   This is why your course, which is much wider than the
courses we've had up until now, is quite slow.  I'll add real VFC to my
TODO list.

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

Yes, absolutely. I want be able to set the course lighting and the wind
velocity, too.

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

Yet another good idea.

Thanks,
Jasmin

This message was sent from Geocrawler.com by "eric kmetz" <er...@ve...>
Be sure to reply to that address.

Okay so I just bought this nvidia TNT2 32MB video
card about a week ago.  Got their glx.so/libGL
drivers and their X server.  Got quake3 up and
going but tuxracer basically broke my X.

So i visited utah-glx, recompiled Mesa GL/GLU/glut
with nv driver support, installed, swapped back to
normal SVGA X server with the utah glx module
still loading.

And still tuxracer crashes my X server. I've tried
./configure'ing --with-x.. thats about the extend
of things.

Heres the X server output:

XFree86 Version 3.3.5 / X Window System
(protocol Version 11, revision 0, vendor release
6300)
Release Date: August 23 1999
        If the server is older than 6-12 months,
or if your card is newer
        than the above date, look for a newer
version before reporting
        problems.  (see
http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.5-15 i686 [ELF]
Configured drivers:
  SVGA: server for SVGA graphics adaptors
(Patchlevel 0):
      NV1, STG2000, RIVA 128, RIVA TNT, RIVA TNT2,
RIVA ULTRA TNT2,
      RIVA VANTA, RIVA ULTRA VANTA, RIVA
INTEGRATED, GeForce 256,
      GeForce DDR, Quadro, generic
(using VT number 7)

XF86Config: /etc/XF86Config
(**) stands for supplied, (--) stands for
probed/default values
(**) XKB: keycodes: "xfree86"
(**) XKB: types: "default"
(**) XKB: compat: "default"
(**) XKB: symbols: "us(pc101)"
(**) XKB: geometry: "pc"
(**) XKB: rules: "xfree86"
(**) XKB: model: "pc101"
(**) XKB: layout: "us"
(**) Mouse: type: Microsoft, device: /dev/mouse,
baudrate: 1200
(**) Mouse: buttons: 3
(**) SVGA: Graphics device ID: "Primary Card"
(**) SVGA: Monitor ID: "Primary Monitor"
(--) no ModulePath specified using default:
/usr/X11R6/lib/modules
Sucessfully loaded XFree86 3.3 symbols
        GLX extension module for XFree86 3.3.3.1
-- Mesa version 3.1
                GLX package version 0.9, GLX
protocol version 1.2.
(**) module glx.so successfully loaded from
/usr/X11R6/lib/modules
(**) FontPath set to
"/usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscal
ed,/usr/X11R6/lib/X11/fonts/100dpi:unscaled,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/font
s/Speedo,/usr/X11R6/lib/X11/fonts/misc,/usr/X11R6/lib/X11/fonts/75dpi,/usr/X11R6/lib/X11/fonts/100
dpi"
(--) SVGA: PCI: NVidia Riva Ultra Vanta rev 17,
Memory @ 0xe4000000, 0xe6000000
(--) SVGA: chipset:  RIVA ULTRA TNT2
(--) SVGA: videoram: 32640k
(**) SVGA: Option "dac_8_bit"
(**) SVGA: Using 32 bpp, Depth 24, Color weight:
888
(--) SVGA: Maximum allowed dot-clock: 350.000 MHz
(**) SVGA: Mode "1024x768": mode clock = 115.500
(**) SVGA: Mode "800x600": mode clock =  69.650
(**) SVGA: Mode "640x480": mode clock =  45.800
(**) SVGA: Mode "640x400": mode clock =  31.500
(**) SVGA: Mode "512x384": mode clock =  22.000
(**) SVGA: Mode "480x300": mode clock =  20.950
(**) SVGA: Mode "400x300": mode clock =  18.000
(**) SVGA: Mode "320x240": mode clock =  15.750
(**) SVGA: Mode "320x200": mode clock =  12.590
(--) SVGA: Virtual resolution set to 1024x768
(--) SVGA: RIVA ULTRA TNT2: Using hardware cursor
nvisual=32 (0+32)
(--) SVGA: Using XAA (XFree86 Acceleration
Architecture)
(--) SVGA: XAA: Solid filled rectangles
(--) SVGA: XAA: Screen-to-screen copy
(--) SVGA: XAA: 8x8 color expand pattern fill
(--) SVGA: XAA: Using 8 128x64 areas for pixmap
caching
(--) SVGA: XAA: Caching tiles and stipples
(--) SVGA: XAA: Horizontal and vertical lines and
segments
Initializing logs
Sucessfully loaded XF86_SVGA server symbols
Sucessfully loaded nv driver

RIVA GLX Version = 1.2
Creating new client: 8!
Adding client as resource: 570425344!
### Creating new xsmesa context for Riva...
Adding drawable 33554433 to glWindows list:

Fatal server error:
Caught signal 11.  Server aborting

When reporting a problem related to a server
crash, please send
the full server output, not just the last
messages             

xinit:  connection to X server lost.^M
X connection to :0.0 broken (explicit kill or
server shutdown).^M
wmaker warning: got signal 1 (Hangup) -
exiting...               

Geocrawler.com - The Knowledge Archive

Ok, my first level is more or less ready. Its still needs some fixing,
but should be enough to have some fun. Its available at:

http://pingus.seul.org/~grumbel/5.tar.gz

-- 
ICQ: 59461927                                    http://pingus.seul.org | 
Ingo Ruhnke <gr...@gm...>             http://home.pages.de/~grumbel/ |
------------------------------------------------------------------------+

On Wed, 1 Mar 2000, Steve Baker wrote:

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

Patch against 0.10.1 attached that addresses both of these issues.
New config parameters: force_window_position and warp_pointer, both
default to true (1).

Cheers,
Jasmin

Jasmin Patry wrote:

> > Anyway, I have a track of sorts done - where would you like me to
> > post it?
> 
> Email to my account is fine if it's not too large (under ~1 MB, say).

It's pretty small...so I'll attach it here.

> Eventually I'll have to figure out a better way for people to submit
> courses; I don't think SourceForge allows for anon ftp uploads
> anywhere...

You could set up a CVS archive for the levels and give access to
selected (ie TRUSTED) users to write to it.  That would allow
anyone to whom you granted permission the ability to write to
any of the levels - which is a little dubious - but with CVS,
you can always 'back out' changes if someone does something
inappropriate.

It might be possible to do the same thing with FTP - they won't
allow anonymous access - but they might allow someone with a
sourceforge account who has been granted permission by the
project owner (ie you).

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)
On Wed, 1 Mar 2000, Steve Baker wrote:

> I decided to have a go at designing a level - it's pretty easy but
> I have a couple of questions:

Great! I'll have a go at your questions tomorrow (sleep beckons)...

> Anyway, I have a track of sorts done - where would you like me to
> post it?

Email to my account is fine if it's not too large (under ~1 MB, say).
Otherwise, can you post it to a publicly accessible website and send me
the URL?

Eventually I'll have to figure out a better way for people to submit
courses; I don't think SourceForge allows for anon ftp uploads
anywhere...

Cheers,
Jasmin

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

tuxracer-devel Mailing List for Tux Racer (Page 6)

tuxracer-devel — Mailing list for Tux Racer developers