plib-devel

Re: [Plib-devel] Mac Updates/Patches (Tux too!)

[Darrell W. <dwa...@pu...>]

For relative paths, I am pretty sure folders end in ':' and files do not.

For PLIB, I think we will make all our paths relative. Therefore *all* paths
will have ':' at the beginning. Since we are not opening directories,
I don't think we have to worry about trailing ':'

so UNIX ->  "foo.bar" -> MAC ":foo.bar"

or "../foo.bar" -> "::foo.bar"

UNIX -> /usr/local/share -> MAC ":usr:local:share"

Hopefully that last one doesn't come up too often ;-) We just have to remind
developers to always use relative pathnames (even on UNIX/WINDOWS) and we
should have no problems.

This reminds me, when needing full paths, like for home directory or
whatnot, I think the usual is to call  getenv ("HOME"). But MacOS has no
concept of $HOME. In fact, the CodeWarrior C Library function getenv() on
MacOS always returns NULL.

I think we should add getHome to our file class.
The MacOS version can return the path to the preferences folder (global
place where 99% of Mac apps store settings, hence why mine has 500 some-odd
files in it ;-) ).


> From: "Norman Vine" <nh...@ca...>
> Reply-To: pli...@li...
> Date: Thu, 3 Aug 2000 23:58:00 -0400
> To: <pli...@li...>
> Subject: Re: [Plib-devel] Mac Updates/Patches (Tux too!)
> 
> FYI --- Generalized Mac Path conversions are not really as kissable
> as they might at first appear :-(
> 
> Following sniped from dis...@py...
> 
>>>> Unfortunately, it seems like sometimes the trailing ":" is required.
> To
>>>> explain why, I need to explain a little bit more about mac pathnames.
> On
>>>> the mac, a path starting with a colon is relative, while one which
> doesn't
>>>> start with a colon is absolute (ie. the reverse of the posix
> convention),
>>>> _unless_ it's just a single name (ie. no colons whatsoever) in which
> case
>>>> it's relative.  The end result of this is that "Macintosh HD" refers to
> a
>>>> file in the local directory called "Macintosh HD" (as does ":Macintosh
>>>> HD"), while "Macintosh HD:" refers to the root directory of the hard
> disk
>>>> "Macintosh HD".
>>>> 
>>>> However, "Macintosh HD:Applications:" and "Macintosh HD:Applications"
> are
>>>> the same thing as each other. Similarly ":Macintosh HD:Applications:"
> and
>>>> ":Macintosh HD:Applications" are the same as each other.
>>> 
>>> Ooh, tricky!  Now I can see why Mac OS doesn't have a command-line
>>> interface: if users can't understand the difference between "/foo" and
>>> "foo", how on earth will they understand that "foo" == ":foo" != "foo:",
>>> while "foo:bar" == ":foo:bar" (but "foo:bar" == "foo:bar:" and
>>> ":foo:bar" == ":foo:bar:").  Aieee!  Doesn't quite rival VMS for
>>> complexity, but it's getting there.
>> 
>> Actually it's
>> 
>> ":foo" == "foo" != "foo:"
>> 
>> but
>> 
>> ":foo:bar" != "foo:bar" == "foo:bar:"
>> 
>>>> There's a similar problem with ":", "::", etc.  Removing a trailing ":"
> in
>>>> these cases directly affects the meaning.
>>> [...]
> 
> Norman
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Mac Updates/Patches (Tux too!)

[Norman V. <nh...@ca...>]

FYI --- Generalized Mac Path conversions are not really as kissable
as they might at first appear :-(

Following sniped from dis...@py...

>> > Unfortunately, it seems like sometimes the trailing ":" is required.
To
>> > explain why, I need to explain a little bit more about mac pathnames.
On
>> > the mac, a path starting with a colon is relative, while one which
doesn't
>> > start with a colon is absolute (ie. the reverse of the posix
convention),
>> > _unless_ it's just a single name (ie. no colons whatsoever) in which
case
>> > it's relative.  The end result of this is that "Macintosh HD" refers to
a
>> > file in the local directory called "Macintosh HD" (as does ":Macintosh
>> > HD"), while "Macintosh HD:" refers to the root directory of the hard
disk
>> > "Macintosh HD".
>> >
>> > However, "Macintosh HD:Applications:" and "Macintosh HD:Applications"
are
>> > the same thing as each other. Similarly ":Macintosh HD:Applications:"
and
>> > ":Macintosh HD:Applications" are the same as each other.
>>
>> Ooh, tricky!  Now I can see why Mac OS doesn't have a command-line
>> interface: if users can't understand the difference between "/foo" and
>> "foo", how on earth will they understand that "foo" == ":foo" != "foo:",
>> while "foo:bar" == ":foo:bar" (but "foo:bar" == "foo:bar:" and
>> ":foo:bar" == ":foo:bar:").  Aieee!  Doesn't quite rival VMS for
>> complexity, but it's getting there.
>
>Actually it's
>
>":foo" == "foo" != "foo:"
>
>but
>
>":foo:bar" != "foo:bar" == "foo:bar:"
>
>> > There's a similar problem with ":", "::", etc.  Removing a trailing ":"
in
>> > these cases directly affects the meaning.
>> [...]

Norman

Re: [Plib-devel] Mac Updates/Patches (Tux too!)

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

"Curtis L. Olson" wrote:

> > What about things like '~' in UNIX (it means "my home directory") and '~fred'
> > (meaning "fred's home directory) ?
> 
> I belive '~' expansion is called "globbing" in unix and is typically
> done at the shell level (i.e. is expanded by the shell.)  The unix
> libc doesn't have any "glob" functionality built in and programs that
> "glob" usually fake it and quite often don't do nearly as nice of a
> job as the shell.  Try writing a simple C program that opens
> "~sjbaker/junk" (the string being hardcoded and not passed in from the
> shell) and see what happens.

Doh!  Of course!  I knew that...  :-)

> > Perhaps it would be smart to define a class that expresses a filename in
> > an OS-neutral manner (eg as an array of strings - so no separators are
> > involved - and the only ".." operators are at the top - and stuff like the
> > Windoze 'C:' drive name and the Linux/UNIX "~" are removed).
> >
> > Then that class could have 'fromUNIX', 'fromMacOS', 'fromWin" and so on to
> > convert existing file names into the class - and then operations like
> > 'fopen' that internally convert to whatever native format the OS needs
> > before doing their work.
> >
> > The application could then be written in whatever native style the author
> > prefers - and the class would convert to whatever target OS is needed.
> >
> > That way, you only have to write a 'fromXXX' and 'toXXX' convertor for
> > each OS in order to have every possibility covered.  Otherwise, we'll
> > be forever writing 'BeOS_to_Amiga', 'CP/M_to_legOS' and such like.
> 
> I will lobby for KISS here.  If you make something that is too all
> encompassing and can handle just about every possible situation the
> most deviant OS designer could come up with there is a good chance you
> will end up with a library that is complex and unwieldy and is a
> hassle to use ... in which case people often won't.

Well, I don't think this would be hard to use:

   ulFilename fname ( "/home/steve/tux/models/tux.ac", UL_UNIX ) ;

...or...

   ulFilename fname ( "C:\HOME\STEVE\TUX\MODELS\TUX.AC", UL_WINDOZE ) ;

...or...

   ulFilename fname ( "home:steve:tux:models:tux.ac", UL_MACOS ) ;

...(any of those would work on any of those operating systems)...and then:

   FILE *fd = fname -> fopen ( "r" ) ;

...and that's *it*.

We could go on to add frills like:

   fname . getFileName () ;

...which returns "tux.ac"...or whatever is appropriate for the OS type
the ulFileName was created in.

Internally, converting to and out of a standard internal form wouldn't be that
hard.

> I like the flight gear FGPath class myself.  It can't handle every
> case you could dream up, but it is pretty simple and easy to use (and
> easy to convert hardcoded paths to use FGPath.)  With a little thought
> on the part of the app writer to avoid degenerate situations, the
> FGPath class can be made to work very well ...

I think that with FGFS, you have a slightly easier task.  You have only
one set of users on one (admittedly large) project.  For something like
PLIB, where we don't know where it'll ultimately end up, I think we have
to be more robust.

-- 
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] Mac Updates/Patches (Tux too!)

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

Steve Baker writes:
> > The mac-to-unix conversion would just be separator replacement though. Take
> > the leading ':' and convert to '../' and then for the rest replace ':' with
> > '/'
> 
> What about things like '~' in UNIX (it means "my home directory") and '~fred'
> (meaning "fred's home directory) ?

I belive '~' expansion is called "globbing" in unix and is typically
done at the shell level (i.e. is expanded by the shell.)  The unix
libc doesn't have any "glob" functionality built in and programs that
"glob" usually fake it and quite often don't do nearly as nice of a
job as the shell.  Try writing a simple C program that opens
"~sjbaker/junk" (the string being hardcoded and not passed in from the
shell) and see what happens.

> Perhaps it would be smart to define a class that expresses a filename in
> an OS-neutral manner (eg as an array of strings - so no separators are
> involved - and the only ".." operators are at the top - and stuff like the
> Windoze 'C:' drive name and the Linux/UNIX "~" are removed).
> 
> Then that class could have 'fromUNIX', 'fromMacOS', 'fromWin" and so on to
> convert existing file names into the class - and then operations like
> 'fopen' that internally convert to whatever native format the OS needs
> before doing their work.
>  
> The application could then be written in whatever native style the author
> prefers - and the class would convert to whatever target OS is needed.
> 
> That way, you only have to write a 'fromXXX' and 'toXXX' convertor for
> each OS in order to have every possibility covered.  Otherwise, we'll
> be forever writing 'BeOS_to_Amiga', 'CP/M_to_legOS' and such like.

I will lobby for KISS here.  If you make something that is too all
encompassing and can handle just about every possible situation the
most deviant OS designer could come up with there is a good chance you
will end up with a library that is complex and unwieldy and is a
hassle to use ... in which case people often won't.

I like the flight gear FGPath class myself.  It can't handle every
case you could dream up, but it is pretty simple and easy to use (and
easy to convert hardcoded paths to use FGPath.)  With a little thought
on the part of the app writer to avoid degenerate situations, the
FGPath class can be made to work very well ...

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] Mac Updates/Patches (Tux too!)

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

Darrell Walisser wrote:
> 
> 
> >> Steve, the disappearing
> >> texture problem is back. This may only be an issue for ATI Rage Pro cards
> >> (looks fine in software). I will have a Voodoo3 to test on in  a few days,
> >> maybe it will work on that ;-)
> >
> > It's been a while - about 100,000 emails ago probably!  Can you remind
> > me of the symptoms?
> >
> 
> We added some code to SGI loader so that it always used an alpha channel,
> even if the SGI file didn't contain an alpha channel. Otherwise, the texture
> doesn't display, seemingly getting skipped by the renderer. For example, in
> the opening screen of tux, there is just the water texture at the bottom,
> tux's feet, and other things that contain alpha channel.

Oh - *thats* not good.

(Although I like the ghostly tux-feet!)

Well, I think we have to be looking at an error in your OpenGL implementation,
but I can't imagine what.  Presumably some OpenGL state information isn't
being maintained correctly.

Tux runs on nearly a dozen different OpenGL's now - and the one you are using
is the only one to exhibit anything this strange...I think that has to point
to a problem in the driver.

The fact that forcing all textures to be alpha's cures the problem points
to a possible reason.  Perhaps the alpha channel of non-alpha texture is
left turned on internally to OpenGL - and is defaulting to zero instead of one.

I would suggest that you check this theory by finding all the glEnable(GL_BLEND)
calls in PLIB and change them to glDisable's.  If my theory is correct then the
opaque terrain will return - although the transparent polygons will become opaque
also.  If that works then we are certainly looking at an OpenGL bug.


> I suppose you could include it, but the way it works right now is not
> exactly good programming practice. The compiler inserts a header file I made
> into all sources, looks like this:
> 
> #include <stdio.h>
> 
> extern  FILE* mac_fopen (const char*, const char*);
> #define fopen(x,y) mac_fopen (x,y)

OK - but we could write a 'ulFOpen' that does that - and programs that
want machine-independent file opening can use it in place of fopen.

> The unix-to-mac conversion is pretty hairy because you can't do a simple
> separator replacement. For example, to go to a higher directory on MacOS,
> you append ":" to the *beginning* of the path. In unix you can add /../
> *anywhere* in the path to do the same thing.

well, xxx/yyy/../zzz in UNIX is equivelent to xxx/zzz - so you *could*
filter those intelligently and only turn ../xxx/yyy/zzz into :xxx:yyy:zzz
...but it's certainly not pretty.

> The mac-to-unix conversion would just be separator replacement though. Take
> the leading ':' and convert to '../' and then for the rest replace ':' with
> '/'

What about things like '~' in UNIX (it means "my home directory") and '~fred'
(meaning "fred's home directory) ?

> I guess it would be wise to start working on a ulFile class that takes care
> of these things for you. In that case I'd gladly add the mac-unix and
> unix-mac converter for you.
> 
> Also, of course, you'd have to enforce valid file naming (no '/', ':', '\',
> or '.')

Perhaps it would be smart to define a class that expresses a filename in
an OS-neutral manner (eg as an array of strings - so no separators are
involved - and the only ".." operators are at the top - and stuff like the
Windoze 'C:' drive name and the Linux/UNIX "~" are removed).

Then that class could have 'fromUNIX', 'fromMacOS', 'fromWin" and so on to
convert existing file names into the class - and then operations like
'fopen' that internally convert to whatever native format the OS needs
before doing their work.
 
The application could then be written in whatever native style the author
prefers - and the class would convert to whatever target OS is needed.

That way, you only have to write a 'fromXXX' and 'toXXX' convertor for
each OS in order to have every possibility covered.  Otherwise, we'll
be forever writing 'BeOS_to_Amiga', 'CP/M_to_legOS' and such like.

-- 
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] Problems, mostly with MSVC 6.0

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

Wolfram Kuss wrote:
> 
> I just got the newest stuff from CVS, I want to look at LookAt :-).
> BTW, long involvement in "Pretty Poly Edit" makes you speak
> parrot-like ;-).

It could be worse - think about what happens when you've been working
on Tux games for too long!  :-)
 
> Here are the changes for ssgSave, ssgLoad is analog (sp?):

analogous?  ...yes.

-- 
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] Mac Updates/Patches (Tux too!)

[Darrell W. <dwa...@pu...>]

 
>> Steve, the disappearing
>> texture problem is back. This may only be an issue for ATI Rage Pro cards
>> (looks fine in software). I will have a Voodoo3 to test on in  a few days,
>> maybe it will work on that ;-)
> 
> It's been a while - about 100,000 emails ago probably!  Can you remind
> me of the symptoms?
> 

We added some code to SGI loader so that it always used an alpha channel,
even if the SGI file didn't contain an alpha channel. Otherwise, the texture
doesn't display, seemingly getting skipped by the renderer. For example, in
the opening screen of tux, there is just the water texture at the bottom,
tux's feet, and other things that contain alpha channel.

To better illustrate, here is a screen:

http://icdweb.cc.purdue.edu/~walisser/plib/tux.jpg

>> Also a slight mod in slModFile.cxx to use fopen() instead of open(). I need
>> to use fopen because my unix-to-mac path converter only intercepts fopen()
>> calls.
>> 
>> Looks like this:
>> 
>> slModFile.cxx  560:
>> 
>> int fd = fileno ( fopen ( fname, "rb" ) ) ;
> 
> OK - can we put your UNIX-to-MAC path convertor into PLIB/UTIL somewhere?
> We really need UNIX-to-Windoze, Windoze-to-UNIX, Windoze-to-Mac and
> Mac-to-Windoze
> convertors too.  I've been putting off doing those for a while because there
> was nowhere sensible in PLIB to put them...but now that Dave is off creating
> things like directory searching inside the 'UL' space, we should start to
> address
> the thorny issues of file/path names and (ugh) file line-termination in a
> portable
> manner.

I suppose you could include it, but the way it works right now is not
exactly good programming practice. The compiler inserts a header file I made
into all sources, looks like this:


#include <stdio.h>

extern  FILE* mac_fopen (const char*, const char*);
#define fopen(x,y) mac_fopen (x,y)

The unix-to-mac conversion is pretty hairy because you can't do a simple
separator replacement. For example, to go to a higher directory on MacOS,
you append ":" to the *beginning* of the path. In unix you can add /../
*anywhere* in the path to do the same thing.

The mac-to-unix conversion would just be separator replacement though. Take
the leading ':' and convert to '../' and then for the rest replace ':' with
'/'

I guess it would be wise to start working on a ulFile class that takes care
of these things for you. In that case I'd gladly add the mac-unix and
unix-mac converter for you.

Also, of course, you'd have to enforce valid file naming (no '/', ':', '\',
or '.')

RE: [Plib-devel] ssg animation

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

i made a first pass at these changes because i will need the extra frames
soon.
i'm interested in the realtime/frame-locked feature, but i'm unsure of how
you wanted to implement that so i'll leave it to you.

--Dave

Steve Baker wrote:
> > Dave McClurg wrote:
> > 
> > Proposed changes:
> > 
> > ssgSelector would allow more than 32 frames by adding a 
> max_kids param to the constructor
> > 
> >   ssgSelector ( int max_kids = 32 ) ;
> > 
> > the derived classed ssgRangeSelector and ssgTimedSelector 
> would also take this param.
> 
> What about the current ability (which I use quite a bit) to 
> pass an integer mask
> with one bit per child object to enable you to select 
> multiple child objects at
> once?
> 
> > also, i would like to move this
> > 
> >   _ssgFrameCounter++ ;
> > 
> > from the top of ssgCullAndDraw() to the bottom of 
> ssgCullAndDraw() because i want
> > the animation rate to be based on logic frames and not 
> render frames.
> 
> Yes - that's becoming important.
> 
> I was planning on making a new member function in 
> ssgTimedSelector to allow you
> to ask for either 'realtime' of 'frame-locked' animation.
> 
> There are cases when each is useful - and I'd like to mix 
> them in the same
> application sometimes.
> 
> > I'll just call ssgSetFrameCounter(fc) before calling 
> ssgCullAndDraw().
> 
> That'll work in the short term.
> 
> > My logic frames are scheduled with a timer so that I always 
> have 60 logic frames
> > per second regardless of my render frame rate.  My 
> animation plays correctly
> > on slow machines and fast ones.  I prefer this over 
> non-determistic simulations
> > where the number of logic frames varies and uses floating 
> point time intervals.
> 
> Yes - but there are times when frame-locked synchronisation 
> is *CRITICAL*.
> 
> One example is in a weather simulation model we have at work that does
> lightning bolts.  You need the lightning bolt to appear as briefly as
> possible - yet never NOT happen because the previous frame 
> took too long
> to render.  To make the lightning look brighter, we do the 
> visual trick
> of pre-rendering a black lightning bolt, then doing the white one and
> then another black one.  Its CRUCIAL that each of those three things
> lasts just one frame - irrespective of the elapsed wall-clock time.
> 
> Anyway - doing this per-object rather than for the entire program
> seems crucial to me.
>  

RE: [Plib-devel] LookAt

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

done.

> > Dave McClurg wrote:
> > 
> > I ported gluLookAt to SSG, tested it, and committed the changes
> > 
> > void ssgLookAt ( SGfloat eyex, SGfloat eyey, SGfloat eyez,
> >   SGfloat centerx, SGfloat centery, SGfloat centerz,
> >   SGfloat upx, SGfloat upy, SGfloat upz )
> 
> Good idea - but I have a couple of really minor gripes:
> 
> I think it should be a member function of ssgContext where the other
> camera stuff lives - and rather than slavishly follow the OpenGL
> parameter
> list, we could be a bit more friendly and take three vectors 
> as parameters
> instead of nine floats...something like:
> 
>    void ssgContext::setCameraLookAt ( sgVec3 eye, sgVec3 
> center, sgVec3 up ) ;
> 
> ...then you could still have a non-member function that just works
> on _ssgCurrentContext...
> 
>    void ssgSetCameraLookAt ( sgVec3 eye, sgVec3 center, sgVec3 up ) ;
> 
> ...that would be more in tune with the rest of the package.
> 
> You could also overload it with a version that doesn't need 
> the 'up' parameter
> and just takes it to be (0,0,1) - which is probably good for 
> 99% of applications.
> 
> -- 
> 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 mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Mac Updates/Patches (Tux too!)

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

Darrell Walisser wrote:
> 
> New CodeWarrior projects are available. There is also a MacCVS Pro config
> file to help with setting up CVS access.
> 
> http://icdweb.cc.purdue.edu/~walisser/plib/plib.cw5.sit

Thanks - I'll try to get them online soon.
 
> I have also implemented experimental JS support using InputSprocket. I wish
> I could test it more, but I don't have a joystick yet ( I plan on getting
> one real soon). The new js.h file is attached.

Excellent!
 
> Mostly just to test my unix-to-mac path converter, I did a quick and dirty
> build of tux (with 1 minor modification to source).

Good.

> Steve, the disappearing
> texture problem is back. This may only be an issue for ATI Rage Pro cards
> (looks fine in software). I will have a Voodoo3 to test on in  a few days,
> maybe it will work on that ;-)

It's been a while - about 100,000 emails ago probably!  Can you remind
me of the symptoms?
 
> At any rate, here is my project setup for tux (brief README included):
> 
> http://icdweb.cc.purdue.edu/~walisser/plib/tux.cw5.sit

OK.
 
> Also a slight mod in slModFile.cxx to use fopen() instead of open(). I need
> to use fopen because my unix-to-mac path converter only intercepts fopen()
> calls.
> 
> Looks like this:
> 
> slModFile.cxx  560:
> 
> int fd = fileno ( fopen ( fname, "rb" ) ) ;

OK - can we put your UNIX-to-MAC path convertor into PLIB/UTIL somewhere?
We really need UNIX-to-Windoze, Windoze-to-UNIX, Windoze-to-Mac and Mac-to-Windoze
convertors too.  I've been putting off doing those for a while because there
was nowhere sensible in PLIB to put them...but now that Dave is off creating
things like directory searching inside the 'UL' space, we should start to address
the thorny issues of file/path names and (ugh) file line-termination in a portable
manner.


> Well thats it!

Great!   It's always good to hear from MacOS people.

Now, where did the BeOS dudes vanish to?

-- 
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] makefiles for test programs

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

i see, so ./configure adds the link option
i'm just looking at the Makefile.am (not Makefile) on a windows machine
it was just odd to see -lplibsg and not -lplibul in Makefile.am

--Dave

> > Dave McClurg wrote:
> > 
> > has anyone tried to build some of the test programs under 
> unix lately?
> > they seem to be missing -lplibul
> > for example, examples/src/ssg/tux/Makefile.am does this
> > 
> >         tux_example_LDADD = -lplibssg -lplibsg
> > 
> > will that link without -lplibul?
> 
> No - it won't.  My Makefile (in that directory) says:
> 
> LIBS = -lglut -lGLU -lGL -lplibul   -L/usr/X11R6/lib  -lSM 
> -lICE -lX11 -lXi -lXext -lXmu  -lm                            
>                                        
>                          ^^^^^^^^
>                         No problem here!
> 
> I think you need to:
> 
>   1) Make sure you have up to date examples.
> 
>   2) Remember to re-run './configure' before you remake.
> 
> Hmmm - and if *that* doesn't work...
> 
>   3) If you got the examples from CVS, remember to re-run 
> autoconf, etc
>      before you run ./configure.
> 
>   4) Remove 'config.cache' perhaps.
> 
> 
> -- 
> 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 mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] LookAt

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

> Dave McClurg wrote:
> 
> I ported gluLookAt to SSG, tested it, and committed the changes
> 
> void ssgLookAt ( SGfloat eyex, SGfloat eyey, SGfloat eyez,
>   SGfloat centerx, SGfloat centery, SGfloat centerz,
>   SGfloat upx, SGfloat upy, SGfloat upz )

Good idea - but I have a couple of really minor gripes:

I think it should be a member function of ssgContext where the other
camera stuff lives - and rather than slavishly follow the OpenGL
parameter
list, we could be a bit more friendly and take three vectors as parameters
instead of nine floats...something like:

   void ssgContext::setCameraLookAt ( sgVec3 eye, sgVec3 center, sgVec3 up ) ;

...then you could still have a non-member function that just works
on _ssgCurrentContext...

   void ssgSetCameraLookAt ( sgVec3 eye, sgVec3 center, sgVec3 up ) ;

...that would be more in tune with the rest of the package.

You could also overload it with a version that doesn't need the 'up' parameter
and just takes it to be (0,0,1) - which is probably good for 99% of applications.

-- 
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] makefiles for test programs

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

> Dave McClurg wrote:
> 
> has anyone tried to build some of the test programs under unix lately?
> they seem to be missing -lplibul
> for example, examples/src/ssg/tux/Makefile.am does this
> 
>         tux_example_LDADD = -lplibssg -lplibsg
> 
> will that link without -lplibul?

No - it won't.  My Makefile (in that directory) says:

LIBS = -lglut -lGLU -lGL -lplibul   -L/usr/X11R6/lib  -lSM -lICE -lX11 -lXi -lXext -lXmu  -lm                                                                   
                         ^^^^^^^^
                        No problem here!

I think you need to:

  1) Make sure you have up to date examples.

  2) Remember to re-run './configure' before you remake.

Hmmm - and if *that* doesn't work...

  3) If you got the examples from CVS, remember to re-run autoconf, etc
     before you run ./configure.

  4) Remove 'config.cache' perhaps.


-- 
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] Cygwin Util Fixes

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

done.

> Could someone incorporate these into the CVS files
> 
> Thanks
> 
> Norman
> 

[Plib-devel] Mac Updates/Patches (Tux too!)

[Darrell W. <wal...@ho...>]

New CodeWarrior projects are available. There is also a MacCVS Pro config 
file to help with setting up CVS access.

http://icdweb.cc.purdue.edu/~walisser/plib/plib.cw5.sit

I have also implemented experimental JS support using InputSprocket. I wish 
I could test it more, but I don't have a joystick yet ( I plan on getting 
one real soon). The new js.h file is attached.

Mostly just to test my unix-to-mac path converter, I did a quick and dirty 
build of tux (with 1 minor modification to source). Steve, the disappearing 
texture problem is back. This may only be an issue for ATI Rage Pro cards 
(looks fine in software). I will have a Voodoo3 to test on in  a few days, 
maybe it will work on that ;-)

At any rate, here is my project setup for tux (brief README included):

http://icdweb.cc.purdue.edu/~walisser/plib/tux.cw5.sit

Also a slight mod in slModFile.cxx to use fopen() instead of open(). I need 
to use fopen because my unix-to-mac path converter only intercepts fopen() 
calls.

Looks like this:

slModFile.cxx  560:

int fd = fileno ( fopen ( fname, "rb" ) ) ;

Well thats it!

See ya!
Darrell



________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Plib-devel] Problems, mostly with MSVC 6.0

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

I just got the newest stuff from CVS, I want to look at LookAt :-).
BTW, long involvement in "Pretty Poly Edit" makes you speak
parrot-like ;-).

Anyway: 
All the libs compiled fine.

PPE doesn't compile since the arguments for ssgLoad and ssgSave in the
header- and the *.cxx-file are different.
I added the "const" in the parameter-lists in the *.cxx-file and
had do add a cast. This makes PPE work, but I havent looked whether
fname should be const or not. Here are the changes for ssgSave,
ssgLoad is analog (sp?):

int ssgSave ( const char *fname, ssgEntity *ent )
              ^^^^^
{
  if ( fname == NULL || ent == NULL || *fname == '\0' )
    return FALSE ;

  char *extn = file_extension ( (char *) fname ) ;
                                ^^^^^^^^

I also have problems with some of the examples.
Many examples don't compile obviously since the the glu(t) stuff isn't
linked. For example, this is one of the error messages I get for bend:

Linking...
bend.obj : error LNK2001: unresolved external symbol
_glutSwapBuffers@0

BTW, for PPE I have glu32.lib in the linker/input-options
after opengl32.lib.


Also, I have the following errors in majik-demo.cxx:

Compiling...
majik_demo.cxx
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(29) : error
C2143: syntax error : missing ';' before '*'
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(29) : error
C2501: 'ssgSGIHeader' : missing storage-class or type specifiers
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(29) : error
C2501: 'material' : missing storage-class or type specifiers
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(30) : error
C2143: syntax error : missing ';' before '*'
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(30) : error
C2501: 'ssgSGIHeader' : missing storage-class or type specifiers
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(30) : error
C2086: 'ssgSGIHeader' : redefinition
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(30) : error
C2501: 'elevation' : missing storage-class or type specifiers
C:\ppe\cvs\plib\examples\src\ssg\majik\majik_demo.cxx(222) : warning
C4305: 'argument' : truncation from 'const double' to 'float'
E

--
Bye bye,
Wolfram.

[Plib-devel] Cygwin Util Fixes

[Norman V. <nh...@ca...>]

Could someone incorporate these into the CVS files

Thanks

Norman

RE: [Plib-devel] Simple SSG examples

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

Without debugging it, I noticed that

	// Create a simple state - no lighting, no texuring etc.
	ssgSimpleState *state = new ssgSimpleState();
	state->disable(SSG_GL_LIGHTING_EN);

might be causing problems.  Try this instead:

  ssgSimpleState *state = new ssgSimpleState () ;
  state -> disable ( GL_LIGHTING       ) ;

and maybe add:

  state -> disable ( GL_ALPHA_TEST ) ;
  state -> disable ( GL_BLEND ) ;
  state -> setOpaque () ;
 
--Dave

> I've only been using sg in my game so far, so I figured it 
> was about time I got to grips with ssg.  As there's a bit of a lack of
> ssg examples I figured I write some and kill two birds with one stone.
> 
> So, how much more simple can you get than a white rectangle 
> on the screen.  Which is why I feel a bit lame when I can't get it to
> work :)
> 
> Source code is attached - it's v.simple so I can't imagine 
> what's up with it.
> 
> If anyone get's some time maybe they could take a look.
> 
> Sam
> 
> Hmm..Sudden thought - is the SSG co-ordinate system different 
> from the OpenGL convention?
> 
> 

[Plib-devel] LookAt

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

I ported gluLookAt to SSG, tested it, and committed the changes

void ssgLookAt ( SGfloat eyex, SGfloat eyey, SGfloat eyez,
  SGfloat centerx, SGfloat centery, SGfloat centerz,
  SGfloat upx, SGfloat upy, SGfloat upz )

It has the same caveats as the original...

1) In order to compute the line of sight, the eye point must not be equal
   to the center point.
2) The up vector must not be parallel to the line of sight from the eye
   to the center point.

Also, examples/src/util/test_dir is checked in if someone wants
to try and compile/test it under unix for me.

thanks,
--Dave

RE: [Plib-devel] UL test program for reading directories

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

doh! operator error.
i had "prune empty directories" turned on

--Dave

> Have you done an "update" beforehand?
> 
> --
> Wolfram

Re: [Plib-devel] UL test program for reading directories

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

Have you done an "update" beforehand?

--
Wolfram

[Plib-devel] makefiles for test programs

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

has anyone tried to build some of the test programs under unix lately?
they seem to be missing -lplibul
for example, examples/src/ssg/tux/Makefile.am does this

	tux_example_LDADD = -lplibssg -lplibsg

will that link without -lplibul?

-- Dave

[Plib-devel] UL test program for reading directories

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

wincvs won't seem to let me add files to an empty folder
i get the error:

cvs add: cannot open CVS/Entries for reading: No such file or directory

my files are in http://www.pond.net/~davem/stuff/test_dir.zip and they
belong in plib/examples/src/util if anyone wants to try

--Dave

Re: [Plib-devel] Simple SSG examples

[Sam S. <sa...@sp...>]

Re: Co-ordinate system

I tried using the z is up, -ve y into the screen (and +ve y into the screen) system (based on the fact that sgCutout documentation
describes the x,z plane as facing the viewer), but without any joy.

Sam

----- Original Message -----
From: "Sam Stickland" <sa...@sp...>
To: <pli...@li...>
Sent: Thursday, August 03, 2000 1:06 PM
Subject: [Plib-devel] Simple SSG examples


> reading directoriesHi,
>
> I've only been using sg in my game so far, so I figured it was about time I got to grips with ssg.  As there's a bit of a lack of
> ssg examples I figured I write some and kill two birds with one stone.
>
> So, how much more simple can you get than a white rectangle on the screen.  Which is why I feel a bit lame when I can't get it to
> work :)
>
> Source code is attached - it's v.simple so I can't imagine what's up with it.
>
> If anyone get's some time maybe they could take a look.
>
> Sam
>
> Hmm..Sudden thought - is the SSG co-ordinate system different from the OpenGL convention?
>
>

[Plib-devel] Simple SSG examples

[Sam S. <sa...@sp...>]

reading directoriesHi,

I've only been using sg in my game so far, so I figured it was about time I got to grips with ssg.  As there's a bit of a lack of
ssg examples I figured I write some and kill two birds with one stone.

So, how much more simple can you get than a white rectangle on the screen.  Which is why I feel a bit lame when I can't get it to
work :)

Source code is attached - it's v.simple so I can't imagine what's up with it.

If anyone get's some time maybe they could take a look.

Sam

Hmm..Sudden thought - is the SSG co-ordinate system different from the OpenGL convention?