RE: [Plib-devel] Sky code from simgear

[Curtis L. O. <cu...@me...>]

Ben Woodhead writes:
> Ahh, that sounds bigger then I expected. I remember steve saying
> something about that but I had forgot.

It's probably not a five minute job, but I'd think you could get most
of the way there in an evening's work.

> Ahh, what does ssg use for its list classes. They must use something for a
> list of polygons or points

I'll have to defer this to Steve ...

> > <string> could probably be replaced with old style char arrays with
> > the standard libc functions (strcpy, strlen, etc.)
> > 
> Do we really need this in a sky module.

The sky module needs to parse data files and handle paths so one way
or another, yes, you'll need "string" handling (in the generic sense
of the term.)  Unless you want to hardcode all the data in ... which
would probably work for something like the star database, but might
not work as well for things like cloud textures ... especially if
you'd like the user to be able to specify their own.  But, all of this
can be handled reasonably well with standard character arrays.

> >     #include <simgear/compiler.h>
> > 
> > This one is how we abstract out a lot of compiler dependencies (mostly
> > to handle the problem incurred by introducing STL usage such as
> > <vector> and <string>.
> 
> So that should be easily removed.

Well, you should check to make sure we aren't using things that
<simgear/compiler.h> provides, but my guess is that if there is
anything, it probably isn't much (once you strip out the STL usages.)

> >    #include <simgear/math/fg_random.h>
> > 
> > This just abstracts out rand() vs. random() ...
> 
> Ahh, what is the difference, just how you us them.

       The   rand()  function  returns  a  pseudo-random  integer
       between 0 and RAND_MAX.

       The random() function uses a non-linear additive  feedback
       random  number generator employing a default table of size
       31 long integers to return successive  pseudo-random  num­
       bers  in the range from 0 to RAND_MAX.  The period of this
       random  number  generator  is  very  large,  approximately
       16*((2**31)-1).

I think it's possible that a system could provide one, but not the
other.  Linux provides both.

> >    #include <simgear/math/point3d.hxx>
> > 
> > Here we would need to replace all usage of Point3D with sgdvec3
> > (something which I'd eventually like to do throughout the entire
> > sim/flight/terragear project family.)
> 
> Sound easy enough, (I will regret saying that)

You may ... :-)

> >    #include <simgear/math/polar3d.hxx>
> > 
> > This is some routines to do polar arithmatic and conversions.
> 
> I have no idea what this is for or how to replace it.

If worse comes to worse, you could just copy the relevant parts in
with the rest of the sky code.

> >    #include <simgear/misc/fgpath.hxx>
> > 
> > This is the *gear scheme for handling file and directory paths in a
> > platform independent way.
> 
> Doesn't plib have something similar, or is it only partly implemeented.

It's been discussed, but I think we ended up designing something so
powerful and flexible that handled so many special cases that no one
had the time or energy to impliment it. :-) Hehe, feels good to say
that to Steve for once ... :-)

I still stand by the fgpath class as something that will do the job
with minimal fuss and muss.

> >    #include <simgear/xgl/xgl.h>
> > 
> > This could be gotten rid of ... it's from before we were using ssg and
> > doing all our own opengl calls ... anyplace you see xgl**** you can
> > replace it with gl****
> 
> So I would just have to use something like find and replace for
> this. 

You'll want to do something conceptually like sed -e 's/xgl/gl/' but
that might be a little over aggressive.

> Ya, it made alot of the issues easier to find, I was thinking there
> is more to this then meets the eye, but the docs say to use it, it
> could be just droped into place with a project using plib, and
> looking though the code I only saw the constants.h and the paths
> section.

Well the sky code comes as part of simgear, so if you build and
install simgear, you can just use it with out having to worry about
all these things.  But, there is an aversion to lots of stacked
dependencies ... as well as an aversion to huge packages with lots of
overlapping duplicated code and functionality ... as a developer you
end up getting yelled at by someone (or some group) no matter which
approach you take.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org