Re: [tuxracer-devel] Re: Polygonal objects.

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

(Apologies for slow reply - I've been on vacation for two weeks and
have >2000 emails to catch up with!)

Jasmin Patry wrote:
> 
> 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.

Prohibiting the use of 3rd party libraries is silly - and nobody
could possibly stick to it.  What about Mesa?  glibc?

That's a silly rule.

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

It shouldn't be too hard.
 
> 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.

Yes - you would certainly need to use C++  but since C++ can compile C
programs just as well as C can, the implications of switching to C++ is
no more than a couple of lines in a Makefile.

These days, C compilers are often just C++ compilers with some parts
turned off.  There is really no need to stick with C anymore.

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

Yep - just try writing code to intersect hemisphere-capped cylinders with
arbitary geometry!

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

No - only spheres and lines.

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