plib-devel

Re: [Plib-devel] texture repeating

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

Amit Bakshi wrote:
> 
> Try moving your texture coordinates in by 1/2 a texel.
> 
> So if your texture is 256x256, instead of using (0,0)->
> (0,1) use ( 0.5 / 256 , 0.5 / 256 ) -> ( 0.5 / 256 , 1.0 - 0.5 / 256)
> etc. You get the idea.

No - that's not the right answer.  Check my previous post.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] texture repeating

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

"Curtis L. Olson" wrote:

> In ssg is there a way to control whether a texture is set to "repeat"
> or not?

Sure - that's the second and third parameters of ssgSimpleState::setTexture().
 
> I want to slap a texture down on top of a specific area and have the
> texture cover it completely ... texture coordinates of lower corner
> are (0,0), upper corner are (1,1), etc.

Yes - that's correct.
 
> Now, what I'm finding is that if I have a texture that is all black
> along one edge and all white along the other edge, I get some bleed
> across to the opposite edge ...

A classic problem - which setting non-repeating clamps will cure
completely.

> i.e. some of that white on one edge
> scrolls around and shows up on the opposite edge and visa versa for
> the black ... this makes it really ugly to piece together adjacent
> textures because you always can see the joint because of this bleed
> across.

Joining two textures is a harder problem...for which I wrote a FAQ:

   http://web2.airmail.net/sjbaker1/tiling_textures.html

> I'm assuming this is because the ssg textures are by default set to
> repeat, right?

Yes - by default they repeat because that's what most people want.
 
> Do you have any strategies you can share for avoiding this problem?

Check out the FAQ...I just re-read it and I think it covers everything.

It's all rather disappointing for the purist though.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [Plib-devel] VRML Blender files?

[Simon B. <ug...@ya...>]

I found Blender to be a lot like emacs.  It's a pain
in the butt to learn, but it drips power once you know
what you're doing.
--- Dave McClurg <Dav...@dy...> wrote:
> Gil wrote:
> > got to admit to being *completely* flummoxed by
> it.
 Blender seems to do that to everyone but a charmed
> few


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

Re: [Plib-devel] ulError buffer

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

> Dave McClurg wrote:
> 
> > ul's ulSetError buffer is only 256 bytes long!
> >
> > That's a bit short IMHO.
> >
> 2048?

I was going to suggest 1024 - but 2048 will be OK.
You could get really fancy and allocate more if it runs
out.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[Plib-devel] sending objects to hell

[Dave M. <Dav...@dy...>]

In tuxkart/src/herring.cxx i noticed that when a herring is eaten it is
subsequently sent to hell.  (hell means z=-1000000). Is this preferred over
removing the herring from the scene graph?  Is the culling in ssg efficient
enough to quickly throw this out without much processing?

--Dave

Re: [Plib-devel] texture repeating

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

Amit Bakshi writes:
> Try moving your texture coordinates in by 1/2 a texel.
> 
> So if your texture is 256x256, instead of using (0,0)->
> (0,1) use ( 0.5 / 256 , 0.5 / 256 ) -> ( 0.5 / 256 , 1.0 - 0.5 / 256)
> etc. You get the idea.

Hmmm, this seems to help on the higher mipmap levels but not when I
get further from the object, the bleed through starts showing up
again.  I wonder if it is the ssg mipmap generation routine that is
doing this (assuming the texture will be tiled this is what you want)
but assuming the texture isn't going to be tiled, you don't want this.

Steve, is there anyway to control this aspect of mipmap generation in
ssg?

Thanks,

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

[Plib-devel] Re: plib-devel digest, Vol 1 #139 - 4 msgs

[Scott L. <va...@be...>]

> Have you had a look at Parsec (http://www.parsec.org)?
> 
> I know that they don't publish their source (but IIRC they plan to
> release the game itself for free)...

There's an embryonic edition of BattleSphere (www.battlesphere.com)
under development right now.  The project lends itself really nicely
to a scene graph implementation.  My only peeve is the 3 sound limit
in sl.  In the dark future I might be sorely tempted to write a special
windows-only edition that hooks into DirectSound for that component.
Otherwise, the thought of writing this thing for a bunch of different
platforms simultaneously is irresistable!

Scott

Re: [Plib-devel] texture repeating

[Amit B. <am...@de...>]

Try moving your texture coordinates in by 1/2 a texel.

So if your texture is 256x256, instead of using (0,0)->
(0,1) use ( 0.5 / 256 , 0.5 / 256 ) -> ( 0.5 / 256 , 1.0 - 0.5 / 256)
etc. You get the idea.

-Amit

----- Original Message ----- 
From: "Curtis L. Olson" <cu...@me...>
To: <pli...@li...>
Sent: Thursday, August 24, 2000 11:25 AM
Subject: [Plib-devel] texture repeating


> Steve,
> 
> In ssg is there a way to control whether a texture is set to "repeat"
> or not?
> 
> As I start working on runways I'm starting to notice some artifacts.
> 
> I want to slap a texture down on top of a specific area and have the
> texture cover it completely ... texture coordinates of lower corner
> are (0,0), upper corner are (1,1), etc.
> 
> Now, what I'm finding is that if I have a texture that is all black
> along one edge and all white along the other edge, I get some bleed
> across to the opposite edge ... i.e. some of that white on one edge
> scrolls around and shows up on the opposite edge and visa versa for
> the black ... this makes it really ugly to piece together adjacent
> textures because you always can see the joint because of this bleed
> across.
> 
> I'm assuming this is because the ssg textures are by default set to
> repeat, right?
> 
> Do you have any strategies you can share for avoiding this problem?
> 
> Thanks,
> 
> 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
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] texture repeating

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

Steve,

In ssg is there a way to control whether a texture is set to "repeat"
or not?

As I start working on runways I'm starting to notice some artifacts.

I want to slap a texture down on top of a specific area and have the
texture cover it completely ... texture coordinates of lower corner
are (0,0), upper corner are (1,1), etc.

Now, what I'm finding is that if I have a texture that is all black
along one edge and all white along the other edge, I get some bleed
across to the opposite edge ... i.e. some of that white on one edge
scrolls around and shows up on the opposite edge and visa versa for
the black ... this makes it really ugly to piece together adjacent
textures because you always can see the joint because of this bleed
across.

I'm assuming this is because the ssg textures are by default set to
repeat, right?

Do you have any strategies you can share for avoiding this problem?

Thanks,

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

RE: [Plib-devel] ulError buffer

[Dave M. <Dav...@dy...>]

> ul's ulSetError buffer is only 256 bytes long!
> 
> That's a bit short IMHO.
> 
2048?

Re: [Plib-devel] Sky code from simgear

[Wolfram K. <w_...@rz...>]

Ben wrote:

>I was looking though the simgear code, and I was wondering what has to be
>done to just drop the sky code into plib. 

Have you looked into the old discussions (for example "ssg sky")?
A few things to do are:
- Compile fgfs so you can test your changes (I STILL cant compile fgfs
:-(( )
- create a new interface. Games need other prameters than a flight
simulator. For example, a game might want two suns and a green sky.
- Decide how you want to use it in fgfs. One way is to simply use your
new plib sky-class and input the correct parameters. So, fgfs would
say "there is only one sun and the sky is blue".
- Decide how much functionality goes into plib and how much stays in
fgfs. For example, calculating the positions of the sun and stars 
from the date/time AND lat/lon is important for fgfs, unimportant
for most games, MAYBE important for a formula 1 game etc.

>Later Ben

Bye bye,
Wolfram.

Re: [Plib-devel] Networking Code

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

Michael Kurth wrote:
> 
> > So, you NEED a TCP-like protocol where every packet it GUARANTEED to
> arrive for sending
> > "one-shot" messages - AND a UDP-like protocol where time-critical - but
> often-repeated
> > messages may or may not make it.
> >
> 
> If a UDP packet is critical then set a flag in your packet header requesting
> an ACK be sent back. This will of course mean you need to design a method of
> knowing which packets you sent required an ACK, clearing ACK'd packets,
> knowing which ones haven't been ACK'd yet, and resending the packet.

...coping with ACK packets that get lost - resulting in retransmitted packets
appearing twice at the destination...etc, etc, etc.  Notice that the probability
of an ACK getting lost are identical to the probability of an outgoing packet
getting lost.

...coping with an ACK that refers to a packet you already retransmitted.

...realising that packets can now arrive out of sequence (actually, that was
always possible - even with UDP).

There are a lot of nasty little traps you can fall into.

I think that in the end, you are just better off using TCP where it's needed
and UDP when it isn't.  I believe that's what Quake does.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Networking Code

[Michael K. <neg...@ea...>]

> So, you NEED a TCP-like protocol where every packet it GUARANTEED to
arrive for sending
> "one-shot" messages - AND a UDP-like protocol where time-critical - but
often-repeated
> messages may or may not make it.
>

If a UDP packet is critical then set a flag in your packet header requesting
an ACK be sent back. This will of course mean you need to design a method of
knowing which packets you sent required an ACK, clearing ACK'd packets,
knowing which ones haven't been ACK'd yet, and resending the packet.

Obviously this should not be used to replace TCP, but in the case where you
want to send *most* of your packets to the winds and just require a few of
them to be acknowledged this should work well.

RE: [Plib-devel] VRML Blender files?

[Dave M. <Dav...@dy...>]

Gil wrote:
> FWIW, I've downloaded and installed Blender, and I've
> got to admit to being *completely* flummoxed by it.
> Perhaps it's great if you know how to use it, but
> it's completely unlike any modeller I've ever seen
> or used.
> 
Blender seems to do that to everyone but a charmed few
hit *space* and it will bring up a menu that you can read.
otherwise, check out the online tutorial:

http://www.blender.nl/showitem.php?id=3

--Dave

[Plib-devel] VRML Blender files?

[Gil C. <g.c...@ca...>]

Hi,

I'm slowly assembling a suite of VRML 1 files for the loader, and I'd 
appreciate VRML files created with Blender for testing with.  Email them 
directly to me - mailto:g.c...@de... - rather than spamming the 
whole list. I've already got some models from Dave, but there's never 
enough files to test with!

FWIW, I've downloaded and installed Blender, and I've got to admit to being 
*completely* flummoxed by it.  Perhaps it's great if you know how to use 
it, but it's completely unlike any modeller I've ever seen or used.

Thanks for any contributions,

Gil

PS. Don't assume that my requesting files is a sign that the thing's done - 
I'm still a way from checking code back in to CVS!

Re: [Plib-devel] VRML Loader issues

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

Joel Utting wrote:
> 
> Steve Baker wrote:
> >
> > Gil Carter wrote:
> > > I'll be producing a full set of new VRML1 test files for the parser, so
> > > hopefully they should provide a fairer test once they're done.  Since these
> > > won't really form part of the PLIB distribution but would be useful to have
> > > around, where should I put them?  Is there a convenient place in the CVS
> > > tree for them, or would they be better just on my local web site?
> >
> > I guess I could create a place for them on CVS - but perhaps a better
> > idea would be to use them in the examples area for some kind of small
> > demo or something.  That way they serve dual purpose and aren't such
> > a waste of bandwidth.
> >
> > As an alternative, I suppose we could ask SourceForge for another
> > account for free models.  They seem to be giving accounts away to
> > anyone who asks as far as I can tell.
> 
> This would be great - I was looking for free 3D models at 3dcafe, but
> they had a licence agreement, that I thought was a little restrictive
> (non-commercial use stuff). It would be good to have a repository of
> completely free models, it would be a good place to put test models for
> prettypoly too.
> 
> I could certainly setup the site if no one has time for it. (feature
> requests please...)

You are welcome to take all the TuxAQFH and TuxKart models and drop
them into an OpenSourced repository.  Although both TuxKart and AQFH
are GPL'ed, all the models are mine - so I hereby grant you the right
to re-license them under whatever license you see fit providing it
falls under SourceForge's definition of "OpenSource".

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Networking Code

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

Sam Stickland wrote:
> 
> ----- Original Message -----
> From: "Ben Woodhead" <be...@bg...>
> To: <pli...@li...>
> Sent: Wednesday, August 23, 2000 12:01 PM

> As regards the difference between TCP and UDP, *everything* that makes TCP great for file transfer makes it rubbish for streaming
> media and real-time games.  (And vice-versa UDP is great for streaming makes it's rubbish for file transfer).

Well, it depends on what you want.

Take a game like Doom.

Every frame you need to say where the player is - and reply from the server where
all the monsters are.  UDP is great here - if the message get's lost - who cares?
Just wait for the next one.

On the other hand, of you killed a monster - and *that* message got lost then it *is*
a disaster.  To some extent, we don't mind *so* much if the message takes a long time
to get there - but it REALLY MUST get there!

You could get around that by sending the 'live/dead' flag for every monster every
frame - but you'd also need to say which doors were open, how much ammo you have
left, etc, etc.  The amount of data you have to send every frame becomes unacceptable.

So, you NEED a TCP-like protocol where every packet it GUARANTEED to arrive for sending
"one-shot" messages - AND a UDP-like protocol where time-critical - but often-repeated
messages may or may not make it.
 
> Three major issues spring to mind that make TCP unsuitable.
> 
> 1) Every packet is always *guaranteed* to arrive.  This is especially bad for real-time games.  This means that if a packet failed
> to get through it will keep sending it until it does.  I.e..  the lost packet that was sent *ages* ago about where a robot was will
> keep being sent until it arrives, by which time it is hopelessly out of date.  Under UDP if a packet doesn't make it through you can
> send a more up-to-date version rather than constantly sending the old packet again and again.

...except in the cases I describe above - where TCP is *exactly* what you want.
 
> 2) Since it's stream orientated packets have to arrive in order - this makes issue 1) even worse.

...well, again, the order of arrival is critical for *some* things. If you open the door and THEN
fire, you kill the monster - if you do it the other way around, you blow a hole in the door.

*SOMETIMES* re-ordering the packages into the correct sequence is *good*.

You can work around this by layering your own TCP-like handshake on top of UDP if you don't
want to open two message streams for some reason.  Just bear in mind though that lots of
people are working on optimising their servers, routers, gateways & firewalls to make
TCP work well - nobody but you is working on making your protocol work faster.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[Plib-devel] ulError buffer

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

ul's ulSetError buffer is only 256 bytes long!

That's a bit short IMHO.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Sky code from simgear

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

"Curtis L. Olson" wrote:

> <iostream> could probably be fixed by replacing all the cout's with
> printf()'s.

...or ulSetError's.
 
>    #include <simgear/math/polar3d.hxx>
> 
> This is some routines to do polar arithmatic and conversions.

Would it be userful to slerp those uo into SG?
 

Did all the 'ephemeris' stuff 'go away'?

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Sky code from simgear

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

Ben Woodhead wrote:

> > <vector> would require writing a custom list class.
> 
> Ahh, what does ssg use for its list classes. They must use something for a
> list of polygons or points

ssg has a specialised list class - but it's not very general-purpose.
 
> > <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.

Yes - it does stuff like parsing an ASCII file containing a '300 brightest stars'
database.
 

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

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

RE: [Plib-devel] Sky code from simgear

[Ben W. <be...@bg...>]

Ahh, that sounds bigger then I expected. I remember steve saying something
about that but I had forgot.

> A quick perusal of the sky code shows the following potentially
> objectionable items:
> 
> Steve does not want anything relating to STL or namespaces included
> with plib, so the following dependencies would need to be addressed:
> 
>     #include <iostream>
>     #include <vector>
>     #include <string>
>
> <iostream> could probably be fixed by replacing all the cout's with
> printf()'s.

Ya, fprintf, that does not sound to bad.
 
> <vector> would require writing a custom list class.

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

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

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

> 
>    #include <simgear/constants.h>
> 
> These could be easily fixed by copying out constants to wherever they
> are needed.
> 
>    #include <simgear/debug/logstream.hxx>
> 
> This could be easily fixed by replacing instances of FG_LOG() with
> printf() ... although it could be somewhat tedious.

Okey,
 
>    #include <simgear/math/fg_random.h>
> 
> This just abstracts out rand() vs. random() ...

Ahh, what is the difference, just how you us them.

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

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

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

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

> 
> Hope this helps,
> 
> 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
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

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.

Thanks Ben

Re: [Plib-devel] Sky code from simgear

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

Ben Woodhead writes:
> I was looking though the simgear code, and I was wondering what has to be
> done to just drop the sky code into plib. I haven't seen anything that would
> make me think that this would be a problem as of yet. 
> But its in the todo list, am I missing something.
> Later Ben

A quick perusal of the sky code shows the following potentially
objectionable items:

Steve does not want anything relating to STL or namespaces included
with plib, so the following dependencies would need to be addressed:

    #include <iostream>
    #include <vector>
    #include <string>

<iostream> could probably be fixed by replacing all the cout's with
printf()'s.

<vector> would require writing a custom list class.

<string> could probably be replaced with old style char arrays with
the standard libc functions (strcpy, strlen, etc.)

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

   #include <simgear/constants.h>

These could be easily fixed by copying out constants to wherever they
are needed.

   #include <simgear/debug/logstream.hxx>

This could be easily fixed by replacing instances of FG_LOG() with
printf() ... although it could be somewhat tedious.

   #include <simgear/math/fg_random.h>

This just abstracts out rand() vs. random() ...

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

   #include <simgear/math/polar3d.hxx>

This is some routines to do polar arithmatic and conversions.

   #include <simgear/misc/fgpath.hxx>

This is the *gear scheme for handling file and directory paths in a
platform independent way.

   #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****

Hope this helps,

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

[Plib-devel] Sky code from simgear

[Ben W. <be...@bg...>]

Hello 

I was looking though the simgear code, and I was wondering what has to be
done to just drop the sky code into plib. I haven't seen anything that would
make me think that this would be a problem as of yet. 
But its in the todo list, am I missing something.
Later Ben

[Plib-devel] New Network Code

[Ben W. <be...@bg...>]

Hey, 

Well, I thought I would work on the networking code again this afternoon and
things went alot better. I have also reorganized the code because it was
getting unreadable.

Here it is.

Later Ben
This is only the TCP section