Thread: Re: [Plib-devel] PLIB developers needed.

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

I'm registered as gilcarter at Sourceforge.  If Steve adds me to the CVS 
write crowd, there's no more excuses...

Gil

What does being a PLIB developer entail?  I'm interested in supporting PUI,
but my day job keeps getting in the way.  How many hours a week are you
talking about?  What sort of things does a formal developer do?

John F. Fay
joh...@eg...

-----Original Message-----
From: Steve Baker [mailto:sjb...@ai...]
Sent: Tuesday, August 08, 2000 21:42
To: PLIB-devel
Subject: [Plib-devel] PLIB developers needed.

I'm feeling severely swamped by the amount of PLIB stuff that's heading
my way recently.  There have been a lot of really good things offered - but
I just don't have time to fit them all in.  Dave is doing great work - but
we really need a couple more people just like him!

There are a couple of hundred people subscribed to the various PLIB mailing
lists.  Would anyone else like to step forward as an active developer
(with CVS write access) ?

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

Fay John F Contr AAC/WMG wrote:

> What does being a PLIB developer entail?

Well, any or all of the following:

1) Having great ideas - turning them into working code - committing them.

2) Getting great ideas from other people - turning them into working code - committing them.

3) Getting code from other people - making sure it works - committing it.

4) Committing patches from other people who aren't registered developers but
   whom we trust.

5) Documentation.

6) Perhaps volunteering to take over and "own" one of the library chunks in PLIB.

7) Perhaps taking over maintenance of the PLIB web site.

8) Perhaps taking over the main release mechanism for PLIB.

Right now - I'd be happy to let anyone I know moderately well from past
history do any of the first five things - for the last three, it would
have to be someone I know *WELL* and who has contributed quite a bit of
good stuff.

>  I'm interested in supporting PUI,
> but my day job keeps getting in the way.

Yep - my problem in a nutshell.

>  How many hours a week are you talking about?

As many or as few as you can contribute.  You could make
a useful impact with just a few hours a week.

> What sort of things does a formal developer do?

Well, the only difference between a formal developer and a typical
list member is that you have access rights that allow you to change
the code/examples/documents for PLIB without having to go through
Dave or myself to get changes actually committed.

There is an element of trust here.  I obviously have to give up a
measure of control - and yet trust that someone whom I give write
access to isn't going to make a horrible mess of the architecture.

You have to trust that I won't go and undo all your hard work after
you've gone to all the trouble of committing it.

Dave and I seem to agree on most things - so it's going smoothly
so far...we need to go carefully to avoid personality problems
in the future.

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

I'm supposed to have CVS write access to PLIB, but it doesn't
work.  I have the ssgVtxArray changes to use shorts in the
ssgIndexArray instead of ints.  Its ready to commit.  The
commit says I don't have write access.

Here is what I did:
- anonymous checkout of all of plib;
- verify that plib still works for me (it does);
- checkout (as markus5, my sourceforge ID) the 3 files that are changing;
- change the files;
- commit (as markus5) the 3 files that changed.

The commit says I don't have write access.
Any ideas?

My PLIB changes are here, if anyone cares:
http://vallevand.homepage.com/plib/ssg.h
http://vallevand.homepage.com/plib/ssg.cxx
http://vallevand.homepage.com/plib/ssgVtxArray.cxx

I'd prefer not to ask Steve to commit the changes, so any ideas about
how I messed up are appreciated.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> There are a couple of hundred people subscribed to the 
> various PLIB mailing
> lists.  Would anyone else like to step forward as an active developer
> (with CVS write access) ?
> 
> -- 
> Steve Baker 

Mark K Vallevand writes:
>
>I'm supposed to have CVS write access to PLIB, but it doesn't
>work.  I have the ssgVtxArray changes to use shorts in the
>ssgIndexArray instead of ints.  Its ready to commit.  The
>commit says I don't have write access.
>
>Here is what I did:
>- anonymous checkout of all of plib;
>- verify that plib still works for me (it does);
>- checkout (as markus5, my sourceforge ID) the 3 files that 
>are changing;
>- change the files;
>- commit (as markus5) the 3 files that changed.
>
>The commit says I don't have write access.
>Any ideas?

Hmm..

Are you using Internet Explorer ??

If so login from http://www.sourceforge.net 
and click the leave SSL mode box
more Info on login page

Norman

"Vallevand, Mark K" wrote:
> 
> I'm supposed to have CVS write access to PLIB, but it doesn't
> work.

Well, I've checked - and you certainly ARE on the write access list:

   markus5   - Mark
   mcdave    - Dave
   sjbaker   - Steve
   sps196    - Sam

There are at least 4 HOWTO/FAQ documents specifically for Windoze users
somewhere on Sourceforge...erm....here:

       http://sfdocs.sourceforge.net/sfdocs/

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

Mark K Vallevand writes:
>
>I'm supposed to have CVS write access to PLIB, but it doesn't
>work.  
>
>Here is what I did:
>- anonymous checkout of all of plib;
>- verify that plib still works for me (it does);
>- checkout (as markus5, my sourceforge ID) the 3 files that 
>are changing;
>- change the files;
>- commit (as markus5) the 3 files that changed.
>
>The commit says I don't have write access.
>Any ideas?

Mark 

You wouldn't perchance be trying to update from a branch 
where the ./cvs/root file reads as
:pserver:ano...@cv...:/cvsroot/plib

would you ??

if so try changing it to read
ma...@cv...:/cvsroot/plib

You can only update from a tree / branch checked out by a 
'known' user in a SSH CVS repository.

This might not have been set correctly since you did the 
initial checkout annonymously.

Norman

No, I'm a Netscape guy (always have been, always will be).
But, I didn't login from Netscape.  It wasn't even up.  I was
doing this all from the command line.  WinNT 4.0 SP6a.  I use
ksh from MKS Toolkit as my shell.  I didn't use SSH.

I'll try logging in from Netscape next time.  I'll try with
and without SSH.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> -----Original Message-----
> From: Norman Vine [mailto:nh...@ca...]
> Sent: Wednesday, August 09, 2000 12:49 PM
> To: pli...@li...
> Subject: RE: [Plib-devel] PLIB developers needed.
> 
> 
> Mark K Vallevand writes:
> >
> >I'm supposed to have CVS write access to PLIB, but it doesn't
> >work.  I have the ssgVtxArray changes to use shorts in the
> >ssgIndexArray instead of ints.  Its ready to commit.  The
> >commit says I don't have write access.
> >
> >Here is what I did:
> >- anonymous checkout of all of plib;
> >- verify that plib still works for me (it does);
> >- checkout (as markus5, my sourceforge ID) the 3 files that 
> >are changing;
> >- change the files;
> >- commit (as markus5) the 3 files that changed.
> >
> >The commit says I don't have write access.
> >Any ideas?
> 
> Hmm..
> 
> Are you using Internet Explorer ??
> 
> If so login from http://www.sourceforge.net 
> and click the leave SSL mode box
> more Info on login page
> 
> Norman
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Mark K Vallevand writes:
>
>No, I'm a Netscape guy (always have been, always will be).
>But, I didn't login from Netscape.  It wasn't even up.  I was
>doing this all from the command line.  WinNT 4.0 SP6a.  I use
>ksh from MKS Toolkit as my shell.  I didn't use SSH.

Hmm..
I bet you need SSH.

FWIW
I use the Cygwin Toolkit V1.1.4

and SSH from
   - package availability
     - on ftp.franken.de
     - in /pub/win32/develop/gnuwin32/cygwin/porters/Vinschen_Corinna/V1.1.3
     - as openssh-2.1.1p4.tar.gz,
          openssh-2.1.1p4-src.tar.gz

and CVS from
  ftp://sourceware.cygnus.com/pub/cygwin/private/cygwin-extras-392/

and am having no problems from a bash shell in Win98
uploading to sourcegear via SSH.

The latest Cygwin SSH is almost painless :-)

Cheers

Norman

Roger, wilco.  Tonight.  Maybe.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> Hmm..
> I bet you need SSH.
> 
> Cheers
> 
> Norman

Wolfram Kuss wrote:
> BTW, it *MIGHT* be that I have to rewrite the
> *.x loaders/writers in Mdi_edit in some time, then I would 
> probably write some for plib at the same time.
> *.x is Micro$ofts Direct3D file format, mainly used for games.
> Dave (or anybody else), if I want to see how a loader/writer works,
> which should I look at? It should be farily easy to understand,
> fairly complete and the format should be fairly straight-forward
> (list of vertices/list of faces).
> Its absolutely not clear I would do this, but if then I will probably
> only implement the ASCII-*.x-format, not the binary one.

i couldn't find examples of the ASCII-*-x format, only references in the
documentation.  Tons of binary .x format examples but that is yucky.

ssgLoadAC.cxx contains the most stable, easy to understand, and complete
loader in SSG.  It is what I used to start writing new loaders/exporters.

I'm trying to unify the loaders around ssgParser.cxx which keeps track of
file/line information for error messages and tokenizes each line.  ssgParser
also can track brace/block levels.  I'm using this for ASE and plan on using
it for WRL.  Eventually, I want to go back and fix OBJ,DXF and TRI to use
this.  So... you may also want to look at ssgLoadASE.cxx for a more complex
example.

-- Dave McClurg
mailto:dav...@dy...         http://www.dynamix.com
mailto:da...@po... (home)            http://www.pond.net/~davem 

Dave wrote:

>i couldn't find examples of the ASCII-*-x format, only references in the
>documentation.  Tons of binary .x format examples but that is yucky.

Oh! Do you remember where?
BTW, IIRC, Micro$oft gives away a converter to convert between ASCII
and binary *.x files.

>
>ssgLoadAC.cxx contains the most stable, easy to understand, and complete
>loader in SSG.  [...]

Good, thanks. 

>.  So... you may also want to look at ssgLoadASE.cxx for a more complex
>example.

Ok.

>-- Dave McClurg

Bye bye,
Wolfram.

Steve wrote:
> There is an element of trust here.  I obviously have to give up a
> measure of control - and yet trust that someone whom I give write
> access to isn't going to make a horrible mess of the architecture.
> 

What follows are a few things I've learned working on PLIB.  If you look
through the archives of this mailing list you'll find discussion and reasons
for them.

1) coding conventions
2 space indent
for public symbols in PLIB module 'XX'
(where 'XX' is: SL, SSG, SG, PU, FNT):

#define's, enum tags -- XX_ALL_CAPTIALS
variables -- all_lower_case
functions/classes/structs/typedefs -- xxMixedCase

for private functions, use all_lower_case unless they would pollute the name
space in which case you should use _xxMixedCase
(note the leading underscore).  if a variable pollutes the name space, use
_xxMixedCase.

2) don't use C++ exotics like STL, templates, exceptions, operator
overloading, and iostreams to make porting easier.  if you love that kind of
stuff, you can always wrap plib in your app code.

3) don't add dependencies.  PLIB requires OpenGL and optionally GLUT.  this
is an important and valuable design goal of PLIB.  It sure made it easier to
get PLIB running on a game console because I had to implement a subset of
just *one* API (OpenGL) for the native architecture.
http://www.pond.net/~davem/tinylib

4) For any major change, please consider posting to this list *first*.
Other developers may have a more elegant method of implementing the same
thing or already have a patch that they didn't think anyone else was
interested in.  Perhaps the major change you are thinking about does not
belong in PLIB at all and would be better off in an auxilliary library or
example.

--Dave

> Dave McClurg wrote:

> 2) don't use C++ exotics like STL, templates, exceptions, operator overloading, and iostreams to make porting easier.  if you love that kind of stuff, you can always wrap plib in your app code.

I'd add that classic:

Windoze people: Please don't do this:

    for ( int i = 0 ; i < 10 ; i++ ) whatever ;
    for (     i = 0 ; i < 20 ; i++ ) whatever ;

(It's illegal in modern C++ and although MSVC likes it, GNU C++ doesn't).

Linux people: Please don't do this:

    for ( int i = 0 ; i < 10 ; i++ ) whatever ;
    for ( int i = 0 ; i < 20 ; i++ ) whatever ;

(Although it's perfectly legal C++ - MSVC barfs on it - I forget
 about this *every* time - sorry Windoze dudes!)

Instead, everyone do this:

    int i ;
    for ( i = 0 ; i < 10 ; i++ ) whatever ;
    for ( i = 0 ; i < 20 ; i++ ) whatever ;

(Yuk!)

The 'P' in PLIB stands for "Portability" - and the rest is just a "LIBrary"!

...which reminds me...  :-)

 I tried to compile PLIB on an SGI machine at work - and your 'const-ification' of the clock
routine stopped it from compiling on the IRIX compiler.

You had:

  class ulClock
  {
    ...
    public:
      ...
      int getSomething () const { return something ; }
      ...
   } ;

The 'const' seemed to do *bad* things to the SGI compiler.

Could you remind me what exactly a 'const' right there actually *does*? 

...and then remove them anyway!

> 4) For any major change, please consider posting to this list *first*.  Other developers
> may have a more elegant method of implementing the same thing or already have a patch that
> they didn't think anyone else was interested in.  Perhaps the major change you are thinking
> about does not belong in PLIB at all and would be better off in an auxilliary library or example.

This is by far the most important thing.  I've had one or two really unfortunate cases
where someone has put in a LOT of effort into doing something that wasn't (IMHO) appropriate
for the future of PLIB - so I had to refuse to add them to the package.  In both cases, people
we ...erm...*polite* about it - but it made me feel *REALLY* uncomfortable to have to do it.

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

I didn't see that anyone replied to this so my apologies if I'm
duplicating what someone else wrote.

Steve Baker writes:
> The 'P' in PLIB stands for "Portability" - and the rest is just a "LIBrary"!
> 
> ...which reminds me...  :-)
> 
>  I tried to compile PLIB on an SGI machine at work - and your
> 'const-ification' of the clock routine stopped it from compiling on
> the IRIX compiler.
> 
> You had:
> 
>   class ulClock
>   {
>     ...
>     public:
>       ...
>       int getSomething () const { return something ; }
>       ...
>    } ;
> 
> The 'const' seemed to do *bad* things to the SGI compiler.
> 
> Could you remind me what exactly a 'const' right there actually *does*? 

As best as I can tell, this indicates to the compiler that a call to
foo->getSomething() does not modify foo in anyway.

So if you had a const instance of your class such as:

    const ulClock foo;

Then calling foo.getSomething() is legal.  

It's all part of maintaining const consistancy.

> ...and then remove them anyway!

Const is pretty handy if used correctly ... :-)

Regards,

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

Steve Baker wrote:
> 
>  I tried to compile PLIB on an SGI machine at work - and your 'const-ification' of the clock
> routine stopped it from compiling on the IRIX compiler.
> 
> You had:
> 
>   class ulClock
>   {
>     ...
>     public:
>       ...
>       int getSomething () const { return something ; }
>       ...
>    } ;
> 
> The 'const' seemed to do *bad* things to the SGI compiler.
> 
> Could you remind me what exactly a 'const' right there actually *does*?

Others have already answered that, but I think one point is missing:

This const tells the compiler that ulClock won't be changed by calling
getSomething().

That can cause performance benefits as the compiler can optimize better.
It could e.g. inline that function.
It's also very good for the structure of the code as it prevents any
unwanted access to the data. 
So you can get the excessive type checking at compile time and no subtle
bugs during run time. This gets extremely important when you are using
pointers.

> ...and then remove them anyway!

I doubt that there is a need to remove it. There is a need for the other
code to be made const consistent.

It's *very* important for a library to be const correct! There might be
const correct programs that want to use the library.
But as soon as a const correct program wants to use non const correct
functions it's very likely that the compilation brakes.
The other way round usually works.

As I was writing a const correct FGFS extension (BalloonSim IIRC) it
wouldn't compile as I was heavily using SG. I had the choice to cast all
the consts away or make SG const correct. I did the later (and thus had
to fix half of SSG) as there's no point i casting the consts away. Why
should I use them otherwise?

CU,
Christian

PS: const correctness is quite easy to understand once you tried. (Steve
it shouldn't take you more than 10 minutes). After you've used it a few
times (with paying full attention) it comes automatically.

Christian Mayer wrote:

> > ...and then remove them anyway!
> 
> I doubt that there is a need to remove it. There is a need for the other
> code to be made const consistent.

BUT IT DOESN'T COMPILE ON AT LEAST ONE C++ IMPLEMENTATION.

> It's *very* important for a library to be const correct!

It's **MUCH** more important that it **COMPILE**!

> There might be
> const correct programs that want to use the library.

There are also programs what would like to actually compile without fatal
errors.

> But as soon as a const correct program wants to use non const correct
> functions it's very likely that the compilation brakes.
> The other way round usually works.

It didn't even get through the ul.h header.  There was no other code
involved apart from standard UNIX headers prior to that point. Also,
the program compiles just fine under Linux - so there isn't
anything wrong with my code.

We are looking at a use of 'const' that is in a more recent C++ spec
than IRIX supports (this is just like the declaration-inside-a-for-loop
issue for MSVC).

If we want our code to be portable, we have to forgo some of the
fancier features of C++ in order to get through the lowest-common-denominator
of all C++ compilers.

> As I was writing a const correct FGFS extension (BalloonSim IIRC) it
> wouldn't compile as I was heavily using SG. I had the choice to cast all
> the consts away or make SG const correct. I did the later (and thus had
> to fix half of SSG) as there's no point i casting the consts away. Why
> should I use them otherwise?

I understand that.

> PS: const correctness is quite easy to understand once you tried. (Steve
> it shouldn't take you more than 10 minutes). After you've used it a few
> times (with paying full attention) it comes automatically.

OK - I understand - that's not the point.  A program that compiles
just fine under Linux/g++ doesn't compile under IRIX/C++ - and that's
utterly intolerable.

Am I supposed to be somehow consoled that although my program is
completely unusable, it's wonderfully const-correct.  NO!  Const
is a very small part of making programs that work - I've managed
to write and debug millions of lines of code without it.

Programming is a practical skill - it's all about getting a job done.
A feature that prevents me from compiling is infinitely worse than
the teeny-tiny *theoretical* bug it's trying to correct.

Portability is more important to PLIB than const-correctness.

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

Steve Baker wrote:
> 
> Christian Mayer wrote:
> 
> > > ...and then remove them anyway!
> >
> > I doubt that there is a need to remove it. There is a need for the other
> > code to be made const consistent.
> 
> BUT IT DOESN'T COMPILE ON AT LEAST ONE C++ IMPLEMENTATION.

Chill down. Nobody says that you should brake (or mustn't fix) a
compilation, just because it's correct that way.

I just wanted to say that we should cure the source of the problem and
not the symptoms.

When it comes to consts everyone is tempted to do that.

> > It's *very* important for a library to be const correct!
> 
> It's **MUCH** more important that it **COMPILE**!

I was assuming that it compiles. Otherwise it shouldn't be published...
(I know the limitations of that when it comes to protable code, etc.)

> > But as soon as a const correct program wants to use non const correct
> > functions it's very likely that the compilation brakes.
> > The other way round usually works.
> 
> It didn't even get through the ul.h header.  There was no other code
> involved apart from standard UNIX headers prior to that point. Also,
> the program compiles just fine under Linux - so there isn't
> anything wrong with my code.

Just that it compiles under one system doesn't say that there's nothing
wrong with it.

I don't know what causes it (I don't know any of the affected code). So
it might be your code or it might be the code in the ul.h or perhaps
even something totally different. I don't know it. So I'm not saying
who's guilty.

> We are looking at a use of 'const' that is in a more recent C++ spec
> than IRIX supports (this is just like the declaration-inside-a-for-loop
> issue for MSVC).
> 
> If we want our code to be portable, we have to forgo some of the
> fancier features of C++ in order to get through the lowest-common-denominator
> of all C++ compilers.

I allways thought that const was one of the most basic C++ features.

But anyway, do SG and SSG brake with that compiler? If the answer is no,
that is compiler supporting costs. SG *is* const correct and at least
half of SSG (IIRC).

> > PS: const correctness is quite easy to understand once you tried. (Steve
> > it shouldn't take you more than 10 minutes). After you've used it a few
> > times (with paying full attention) it comes automatically.
> 
> OK - I understand - that's not the point.  A program that compiles
> just fine under Linux/g++ doesn't compile under IRIX/C++ - and that's
> utterly intolerable.

No matter where it compiles. As soon as it doesn't compile on one
(reasonable) system make it intolerable.

> Am I supposed to be somehow consoled that although my program is
> completely unusable, it's wonderfully const-correct.  NO!  Const
> is a very small part of making programs that work - I've managed
> to write and debug millions of lines of code without it.

Of course.

But you can't cry and say 'ban all consts' just because you trip over
one that doesn't work - w/o really knowing if it's the const that causes
the problem or if its breaking the compiler just because the real
problem (probably a forgotten const) stays unnoticed.

> Programming is a practical skill - it's all about getting a job done.
> A feature that prevents me from compiling is infinitely worse than
> the teeny-tiny *theoretical* bug it's trying to correct.

It's not only about bugs. It's also about structure, performance and
probably other thing, too.

> Portability is more important to PLIB than const-correctness.

Definitely. But why shouldn't we try to get both?

CU,
Christian

Christian wrote:
> But anyway, do SG and SSG brake with that compiler? If the answer is no,
> that is compiler supporting costs. SG *is* const correct and at least
> half of SSG (IIRC).
>
I went to fix the 'const' methods in ul.h that are *not* portable on IRIX
when I noticed there were similar 'const' methods already in sg.h like
Christian says.  The 'const' methods in sg.h have been there for a long time
and must work on IRIX.  Perhaps we just need to change
	'double getRawTime () const ;'
to
	'double getRawTime (void) const ;'
and it would work on IRIX.  Seems to be something strange like that.  Do you
want to investigate Steve?

These 'const' methods have been there for a long time...

sg/sg.cxx: int sgBox::intersects ( const sgVec4 plane ) const
sg/sg.cxx: int sgSphere::intersects ( const sgBox *b ) const
sg/sg.cxx: int sgFrustum::getOutcode ( const sgVec3 pt ) const
sg/sg.cxx: int sgFrustum::contains ( const sgVec3 pt ) const
sg/sg.cxx: int sgFrustum::contains ( const sgSphere *s ) const
sg/sgd.cxx: int sgdBox::intersects ( const sgdVec4 plane ) const
sg/sgd.cxx: int sgdSphere::intersects ( const sgdBox *b ) const
sg/sgd.cxx: int sgdFrustum::getOutcode ( const sgdVec3 pt ) const
sg/sgd.cxx: int sgdFrustum::contains ( const sgdVec3 pt ) const
sg/sgd.cxx: int sgdFrustum::contains ( const sgdSphere *s ) const
sg/sg.h:   const SGfloat *getCenter (void) const { return center ; }
sg/sg.h:   SGfloat getRadius (void) const        { return radius ; }
sg/sg.h:   int isEmpty (void) const { return radius <  SG_ZERO ; }
sg/sg.h:   int intersects ( const sgSphere *s ) const
sg/sg.h:   int intersects ( const sgVec4 plane ) const
sg/sg.h:   int intersects ( const sgBox *b ) const ;
sg/sg.h:   const SGfloat *getMin (void) const { return min ; }
sg/sg.h:   const SGfloat *getMax (void) const { return max ; }
sg/sg.h:   int isEmpty(void) const
sg/sg.h:   int intersects ( const sgSphere *s ) const
sg/sg.h:   int intersects ( const sgBox *b ) const
sg/sg.h:   int intersects ( const sgVec4 plane ) const ;
sg/sg.h:   int getOutcode ( const sgVec4 src ) const ;
sg/sg.h:   SGfloat  getHFOV (void) const { return hfov  ; }
sg/sg.h:   SGfloat  getVFOV (void) const { return vfov  ; }
sg/sg.h:   SGfloat  getNear (void) const { return nnear ; }
sg/sg.h:   SGfloat  getFar  (void) const { return ffar  ; }
sg/sg.h:   SGfloat  getLeft (void) const { return left  ; }
sg/sg.h:   SGfloat  getRight(void) const { return right ; }
sg/sg.h:   SGfloat  getTop  (void) const { return top   ; }
sg/sg.h:   SGfloat  getBot  (void) const { return bot   ; }
sg/sg.h:   void getFOV ( SGfloat *h, SGfloat *v ) const
sg/sg.h:   void getNearFar ( SGfloat *n, SGfloat *f ) const
sg/sg.h:   int  contains ( const sgVec3 p ) const ;
sg/sg.h:   int  contains ( const sgSphere *s ) const ;
sg/sg.h:   const SGDfloat *getCenter (void) const { return center ; }
sg/sg.h:   SGDfloat getRadius (void) const         { return radius ; }
sg/sg.h:   int isEmpty (void) const { return radius <  SGD_ZERO ; }
sg/sg.h:   int intersects ( const sgdSphere *s ) const
sg/sg.h:   int intersects ( const sgdVec4 plane ) const
sg/sg.h:   int intersects ( const sgdBox *b ) const ;
sg/sg.h:   const SGDfloat *getMin (void) const { return min ; }
sg/sg.h:   const SGDfloat *getMax (void) const { return max ; }
sg/sg.h:   int isEmpty(void) const
sg/sg.h:   int intersects ( const sgdSphere *s ) const
sg/sg.h:   int intersects ( const sgdBox *b ) const
sg/sg.h:   int intersects ( const sgdVec4 plane ) const ;
sg/sg.h:   int getOutcode ( const sgdVec4 src ) const ;
sg/sg.h:   SGDfloat  getHFOV (void) const { return hfov  ; }
sg/sg.h:   SGDfloat  getVFOV (void) const { return vfov  ; }
sg/sg.h:   SGDfloat  getNear (void) const { return nnear ; }
sg/sg.h:   SGDfloat  getFar  (void) const { return ffar  ; }
sg/sg.h:   SGDfloat  getLeft (void) const { return left  ; }
sg/sg.h:   SGDfloat  getRight(void) const { return right ; }
sg/sg.h:   SGDfloat  getTop  (void) const { return top   ; }
sg/sg.h:   SGDfloat  getBot  (void) const { return bot   ; }
sg/sg.h:   void getFOV ( SGDfloat *h, SGDfloat *v ) const
sg/sg.h:   void getNearFar ( SGDfloat *n, SGDfloat *f ) const
sg/sg.h:   int  contains ( const sgdVec3 p ) const ;
sg/sg.h:   int  contains ( const sgdSphere *s ) const ;

These are the 'const' methods I recently touched...

util/ulClock.cxx: double ulClock::getRawTime () const
fnt/fnt.h:   virtual int   isFixedPitch () const    = 0 ;
fnt/fnt.h:   virtual float getWidth     () const    = 0 ;
fnt/fnt.h:   virtual float getGap       () const    = 0 ;
fnt/fnt.h:   int   isFixedPitch () const    { return fixed_pitch ; }
fnt/fnt.h:   float getWidth     () const { return width     ; }
fnt/fnt.h:   float getGap       () const { return gap       ; }
fnt/fnt.h:   void getCursor ( float *x, float *y, float *z ) const
fnt/fnt.h:   fntFont *getFont () const { return font ; }
fnt/fnt.h:   float getSlant     () const { return italic    ; }
fnt/fnt.h:   float getPointSize () const { return pointsize ; }
pui/pu.h:   const char *getLegend ( void ) const { return legend ; }
pui/pu.h:   const char *getLabel ( void ) const { return label ; }
pui/pu.h:   int getNumItems() const { return num ; }
pui/pu.h:   int getTopItem() const { return top ; }
ssg/ssg.h:   int getMaxKids (void) const { return max_kids ; }
util/ul.h:   double getRawTime () const ;
util/ul.h:   double getMaxDelta  () const { return max_delta ; }
util/ul.h:   double getAbsTime   () const { return now   ; }
util/ul.h:   double getDeltaTime () const { return delta ; }
util/ul.h:   double getFrameRate () const { return 1.0 / delta ; }

--Dave

Dave McClurg wrote:
> 
> Christian wrote:
> > But anyway, do SG and SSG brake with that compiler? If the answer is no,
> > that is compiler supporting costs. SG *is* const correct and at least
> > half of SSG (IIRC).
> >
> I went to fix the 'const' methods in ul.h that are *not* portable on IRIX
> when I noticed there were similar 'const' methods already in sg.h like
> Christian says.  The 'const' methods in sg.h have been there for a long time
> and must work on IRIX.

Weird?  That particular program didn't use sg.h - but I'll try it when I
get back to work on Monday.  I havn't tried to recompile PLIB on our ONYX
using the native IRIX compiler (I know it works under GNU G++ under IRIX - but
that's not the point).

>  Perhaps we just need to change
>         'double getRawTime () const ;'
> to
>         'double getRawTime (void) const ;'
> and it would work on IRIX.  Seems to be something strange like that.  Do you
> want to investigate Steve?

Yes - I'll look when I get into work on Monday - I don't have a our $5,000,000
ONYX-2 here at home  :-)

Interestingly, I was using ul.h to measure some benchmarks between GeForce-2
($300+$2000 for the 800MHz PC) and ONYX-2 ($100,000 per graphics 'pipe'+$200,000
for the computer itself) - the GeForce is comfortably beating the ONYX by about
2:1 on polygon throughput and about the same on pixel fill rates!  Even if you
turn on the antialiased rendering (The ONYX's main selling point) - the ONYX is
still only about equal to the GeForce on polygons although it does beats it by
about 2:1 on pixel fill.

**WOW**

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

I fixed puDeleteObject so that it calls a smarter puPopLiveInterface.  This
allows a callback to delete the dialog it belongs to and create a new one.
This is important for chaining together interfaces (hit a button, delete the
old interface, create a new one).

See examples/src/pui/complex.cxx for an example.  hit File->Save and then
when you hit OK or CANCEL it brings up a little message dialog.

the changes have been commited to CVS.

--Dave

Steve Baker wrote:
> 
> Dave McClurg wrote:
> >
> > Christian wrote:
> > > But anyway, do SG and SSG brake with that compiler? If the answer is no,
> > > that is compiler supporting costs. SG *is* const correct and at least
> > > half of SSG (IIRC).
> > >
> > I went to fix the 'const' methods in ul.h that are *not* portable on IRIX
> > when I noticed there were similar 'const' methods already in sg.h like
> > Christian says.  The 'const' methods in sg.h have been there for a long time
> > and must work on IRIX.
> 
> Weird?  That particular program didn't use sg.h - but I'll try it when I
> get back to work on Monday.  I havn't tried to recompile PLIB on our ONYX
> using the native IRIX compiler (I know it works under GNU G++ under IRIX - but
> that's not the point).

Try it please.

> Interestingly, I was using ul.h to measure some benchmarks between GeForce-2
> ($300+$2000 for the 800MHz PC) and ONYX-2 ($100,000 per graphics 'pipe'+$200,000
> for the computer itself) - the GeForce is comfortably beating the ONYX by about
> 2:1 on polygon throughput and about the same on pixel fill rates!  Even if you
> turn on the antialiased rendering (The ONYX's main selling point) - the ONYX is
> still only about equal to the GeForce on polygons although it does beats it by
> about 2:1 on pixel fill.
> 
> **WOW**

But I doubt that we can run the famous Mont Blanc demo from SGI where
you can zoom from a space view of the earth down to the Mont Blanc and
fly around it. On the fair where I saw it (on an ONYX :-)) ) they told
me that the textures had a resolution of 1 metre and you could see the
walking tracks... The major point of the demo was to show of the
internal bus system as it used 300 MB of textures.
I'd wonder if a GeForce with 4x AGP could do that on a computer that has
enough ram.

But that's definitely not a standard PC - yet.

CU,
Christian

>
>But I doubt that we can run the famous Mont Blanc demo from SGI where
>you can zoom from a space view of the earth down to the Mont Blanc and
>fly around it. On the fair where I saw it (on an ONYX :-)) ) they told
>me that the textures had a resolution of 1 metre and you could see the
>walking tracks...

IIRC, that application is also a pretty good demonstration of Performer's 
ClipTextures, which allow the management of much larger textures than will 
fit into physical texture memory.  I think ClipTextures are implemented 
using special hardware on the Onyxes, so that demo will need some major 
surgery to work on a PC!

Gil

Gil Carter wrote:

>> But I doubt that we can run the famous Mont Blanc demo from SGI where
>> you can zoom from a space view of the earth down to the Mont Blanc and
>> fly around it. On the fair where I saw it (on an ONYX :-)) ) they told
>> me that the textures had a resolution of 1 metre and you could see the
>> walking tracks...
> 
> IIRC, that application is also a pretty good demonstration of Performer's
> ClipTextures, which allow the management of much larger textures than will
> fit into physical texture memory.  I think ClipTextures are implemented
> using special hardware on the Onyxes, so that demo will need some major
> surgery to work on a PC!

It certainly does use clip-texture - that's why they wrote that particular
demo.

However, it's a rather 'rigged' demo because you can only zoom in on
Mont Blanc - you can't (for example) zoom in on a point 10 miles south
of there.

They had a version where you zoomed in past the mountain and onto a
Nintendo-64 (which was developed by SGI) - through the case and down
into the 'Reality Chip'.

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

Steve Baker wrote:
> 
> Gil Carter wrote:
> 
> >> But I doubt that we can run the famous Mont Blanc demo from SGI where
> >> you can zoom from a space view of the earth down to the Mont Blanc and
> >> fly around it. On the fair where I saw it (on an ONYX :-)) ) they told
> >> me that the textures had a resolution of 1 metre and you could see the
> >> walking tracks...
> >
> > IIRC, that application is also a pretty good demonstration of Performer's
> > ClipTextures, which allow the management of much larger textures than will
> > fit into physical texture memory.  I think ClipTextures are implemented
> > using special hardware on the Onyxes, so that demo will need some major
> > surgery to work on a PC!
> 
> It certainly does use clip-texture - that's why they wrote that particular
> demo.

Sorry, but what's the clip-texture really doing?

> However, it's a rather 'rigged' demo because you can only zoom in on
> Mont Blanc - you can't (for example) zoom in on a point 10 miles south
> of there.

But it's been still very impressive (esp. at a time where nobody would
expect 3d accelleration for consumer PCs)

> They had a version where you zoomed in past the mountain and onto a
> Nintendo-64 (which was developed by SGI) - through the case and down
> into the 'Reality Chip'.

Yup, that's the demo I saw. SGI also had a Nintendo-64 prototype at
their booth running SuperMario 64.

CU,
Christian