plib-devel

Re: [Plib-devel] SUNWspro patch, questions

[Loring H. <ls...@cs...>]

Steve Baker wrote:
> > This patch allows PLIB to be built under Solaris w/ the SUNWspro C++ compiler
> > on a system without glut in the default place (ie, adds --with-glut and
> > --with-glut-includes).
> 
> Er - OK - I've merged this stuff in.
> 
> Wouldn't it just be easier to put GLUT in the right place?

Instead of polluting the clean Solaris installs, we use user supported
packages not in the "right" places.  Although it makes using autoconf a pain,
it is a nice way to provide packages publically.

For more info see: http://www.cs.brown.edu/system/software/cs/

> > Also - not sure if it is my version of automake or not (1.4), but automake
> > creates PLIB Makefile's that assume you are using gcc (uses -Md to create
> > dependencies).  I didn't know of any easy way to fix this - it gives a
> > warning message when compiling with SUNWspro 4.2, but builds fine.
> 
> I have no idea - autoconf/automake is a Black Art as
> far as I'm concerned.  Touching configure.in is *scarey*!

Is "scarey" a british spelling? :-)

> Anyway, I've added the new stuff - with fingers crossed  :-)
> 
> <time passes>
> <*lots* of time passes>
> 
> Well, waddayaknow?  It screws up under Linux.
> 
> It seems that with this line in configure.in:
> 
>        CPPFLAGS="$CPPFLAGS -I$x_includes"
> 
> ...causes PLIB modules to compile with:
> 
>        -I/usr/X11R6/include
> 
> ...which causes the *wierdest* symptoms....
[stuff deleted]
> 
> ...I can't understand why that should possibly be. Compiled without /usr/X11R6/include, everything
> works OK?!??!
> 
> However, PLIB doesn't *need* any files from /usr/X11R6/include - so for now I'm committing
> your change but with the offending line commented out - until we can figure WTF is going on.

Actually, it seems like PLIB builds under Solaris even when that line is
commented out.  Sorry for the confusion - feel free to remove it.

Loring

RE: [Plib-devel] Any resolution on the license?

[Paul B. <pbl...@di...>]

> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Subject: Re: [Plib-devel] Any resolution on the license?
> 
> * Since Dave is actually using PLIB on a console himself
>   and is a contributor who DOESN'T want to change the
>   license - I really have to believe that there is a way
>   to stick to the spirit and law of LGPL and still work
>   on PS-2.

I don't want to beat a dead horse, but two quick points
about this (as far as my scenario):

a) We are not developing for the PS-2.  In fact our
APIs will be available on other platforms as it is,
so (I think) all of our source changes would/could
be rolled back into the project.

b) The larger problem is that we cannot provide .o's 
or anything such that those who may want to re-link
with a different version of sg or ssg.  This is the
major sticking point.  As your other post mentions,
companies make decisions.  But that decision means
we cannot follow LGPL -- regardless of ideological
or philosophical arguments.  However, there are other
licenses that would allow us to use ssg/sg and 
contribute back to it.


> I don't really relish the idea of buggy old versions of
> PUI (especially) from that era floating around on the web,
> but so long as people know what they are doing and don't
> do anything stoopid like setting up a non-licensed PLIB
> in competition with the modern LGPL'ed version, I can live
> with that.

The larger problem (that I am trying to avoid) is starting
yet another opensource package just to fix license issues.

As it stands that seems like the only alternative.  I just
wanted to check before I move forward.

Paul

Re: [Plib-devel] [Fwd: [Mesa3d-dev] lighting fixes (fwd)]

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

Curt wrote:
> 
> Steve Baker writes:
> > Yippee!

> (made it back to MN safely although the thunderstorms rumbling through
> Dallas made a real mess of things getting out of there ... we were
> about two hours late getting off the ground.  Never seen so many big
> airplanes in a line.  We were lined up the entire length of the runway
> with about 3 rows bottlenecking into the runway entrance.) :-(

The joys of being the American Airlines Hub!

> I grabbed the latest mesa out of cvs and built it.  But, I got
> software only rendering.

Doh!
 
> Anyone know how to build a libGL from mesa source that works with
> XFree86-4.0 / DRI / Voodoo-3 and all of that?  The configure script
> found my glide.h and libglide3.so ... but apparently there is more to
> it than that.
> 
> Anyone have any tips?

Nothing other than the usual:

1) Make sure X is running in 16bpp - anything else dumps you to software rendering.
   I check using the 'KDE Control Center' tool - click on 'Information' then
   'X-Server'...there is probably a native X tool to do this.  Several times
   I've been suprised to find myself in 24 bpp mode despite asking 'startx' to
   put me in 16 bpp.
2) Either make sure that /dev/3dfx is installed and has rw-rw-rw permissions...or
   run your application as 'root'.
3) Don't demand stuff like stencil planes, alpha planes, etc.
   If you let GLUT pick the defaults you should be OK.
4) Don't forget to "setenv MESA_GLX_FX fullscreen".
5) Use 'ldd' to ensure your application is getting the libGL.so you expect it
   to get (not some weird shit floating around in /usr/local or /usr/X11R6/lib
   or someplace like that - and not libMesaGL.so or something).  If necessary
   use 'find' to track down all the leftover versions and 'rm' them just to be
   certain.
6) Use ldd to ensure that libGL.so is demanding libglide.so.

Does this latest version *have* to use DRI?  If so, then I'm out of my depth - but
I'd wonder whether I had the right modules loaded in XF86Config and whether I have
the right revision and type of X server (I guess if you already have 4.0 then that's
covered already).

This is all getting *WAY* too complicated!

-- 
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] Any resolution on the license?

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

> Norman Vine wrote:
> 
> Dave McClurg  writes:
> 
>>      I'll quit being a roadblock
>>      I agree to whatever license change Steve wants to make.
>>      It will only make my life easier convincing management to let me use plib.
>> 
>>      thanks and sorry for the hassle,
> 
>      Hi Dave
> 
>      You weren't a hassle to me at least.
> 
>      I think that you made some very valid points
> 
>      That a part of me identifies very closely with.

I agree - you've contributed a lot - you have a 'big vote' and if
you want LGPL to stay then I fully support that view.

If it is truly possible (albeit at some low level of difficulty) for
console programmers to adhere to LGPL and use PLIB then I'm personally
against changing the license.

If it's *utterly* impossible for PLIB to be used on consoles - then
bearing in mind that LGPL doesn't make a whole lot of sense to the
end user of the application - *THEN* I might be prepared to yield
and go with Xfree licensing.

If I'm to believe Dave then it's not impossible to live with LGPL
in that setting - so as far as I'm concerned, it's LGPL unless
proven otherwise.

-- 
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] [Fwd: [Mesa3d-dev] lighting fixes (fwd)]

[Curt <cu...@in...>]

Steve Baker writes:
> Yippee!
>
> It looks like the long-standing glColorMaterial bug(s) have finally
> been nailed by Brian Paul of the Mesa team...as we have gradually
> come to suspect, it looks like this has indeed been a Mesa problem
> all along.
>
> I havn't had a chance to try the fixes yet - and I probably won't
> get the time to do so until after SigGraph at the end of July - I'd
> be eternally grateful to anyone with a Linux/Mesa/Voodoo setup who
> could go grab the latest Mesa 3.3 from CVS and report back...either
> way.
>
> Specifically, someone from FGFS ought to try this.

Steve,

(made it back to MN safely although the thunderstorms rumbling through
Dallas made a real mess of things getting out of there ... we were
about two hours late getting off the ground.  Never seen so many big
airplanes in a line.  We were lined up the entire length of the runway
with about 3 rows bottlenecking into the runway entrance.) :-(

I grabbed the latest mesa out of cvs and built it.  But, I got
software only rendering.

Anyone know how to build a libGL from mesa source that works with
XFree86-4.0 / DRI / Voodoo-3 and all of that?  The configure script
found my glide.h and libglide3.so ... but apparently there is more to
it than that.

Anyone have any tips?

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

[Plib-devel] [Fwd: [Mesa3d-dev] lighting fixes (fwd)]

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

Yippee!

It looks like the long-standing glColorMaterial bug(s) have finally
been nailed by Brian Paul of the Mesa team...as we have gradually
come to suspect, it looks like this has indeed been a Mesa problem
all along.

I havn't had a chance to try the fixes yet - and I probably won't
get the time to do so until after SigGraph at the end of July - I'd
be eternally grateful to anyone with a Linux/Mesa/Voodoo setup who
could go grab the latest Mesa 3.3 from CVS and report back...either
way.

Specifically, someone from FGFS ought to try this.

> ---------- Forwarded message ----------
> Date: Mon, 26 Jun 2000 16:58:16 -0600
> From: Brian Paul <br...@pr...>
> To: mesa-dev <mes...@li...>
> Subject: [Mesa3d-dev] lighting fixes
> 
> I've just committed several bug fixes for lighting problems in Mesa.
> First, specular highlights were sometimes in the wrong place.
> Second, glMaterial and glColorMaterial updates to the emissive or
> ambient coefficients weren't always handled correctly.
> 
> I'd appreciate it if people would update their Mesa CVS trees
> and test with your apps to make sure things work better (or as
> the same, if you didn't have this problem).
> 
> -Brian

-- 
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] SUNWspro patch, questions

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

Loring Holden wrote:

> Other issues - the README in cvs is out of date (points to the wrong URL),
> and the documentation is out of date with the cvs source.

Done.

> Would it be
> possible to put the examples and docs in cvs so it would be easier to get the
> most recent versions (and give all the other benefits of cvs)?

That's on my 'ToDo' list.
 
> This patch allows PLIB to be built under Solaris w/ the SUNWspro C++ compiler
> on a system without glut in the default place (ie, adds --with-glut and
> --with-glut-includes).

Er - OK - I've merged this stuff in.

Wouldn't it just be easier to put GLUT in the right place?

> Also - not sure if it is my version of automake or not (1.4), but automake
> creates PLIB Makefile's that assume you are using gcc (uses -Md to create
> dependencies).  I didn't know of any easy way to fix this - it gives a
> warning message when compiling with SUNWspro 4.2, but builds fine.
 
I have no idea - autoconf/automake is a Black Art as
far as I'm concerned.  Touching configure.in is *scarey*!

Anyway, I've added the new stuff - with fingers crossed  :-)

<time passes>
<*lots* of time passes>

Well, waddayaknow?  It screws up under Linux.

It seems that with this line in configure.in:

       CPPFLAGS="$CPPFLAGS -I$x_includes"

...causes PLIB modules to compile with:

       -I/usr/X11R6/include

...which causes the *wierdest* symptoms....

c++  -g -O2 -O6 -Wall  -o tuxkart  start_tuxkart.o tuxkart.o gfx.o material.o gui.o status.o sound.o utils.o isect.o guNet.o loader.o guClock.o Track.o Driver.o Herring.o Explosion.o KartDriver.o Traffic.o PlayerDriver.o AutoDriver.o Projectile.o  -lplibsl -lplibssg -lplibpu -lplibfnt -lplibsg -lglut -lGLU -lGL   -L/usr/X11R6/lib  -lSM -lICE -lpthread -lX11 -lXi -lXext -lXmu  -lm
Herring.o: In function `HerringInstance type_info function':
/u/tuxkart/src/Herring.cxx(.text+0x941): undefined reference to `ssgVtxTable::ssgVtxTable(GLenum, ssgVertexArray *, ssgNormalArray *, ssgTexCoordArray *, ssgColourArray *)'
Herring.o: In function `Shadow::Shadow(float, float, float, float)':
/u/tuxkart/src/Herring.cxx:84: undefined reference to `ssgVtxTable::ssgVtxTable(GLenum, ssgVertexArray *, ssgNormalArray *, ssgTexCoordArray *, ssgColourArray *)'                                                                              

...I can't understand why that should possibly be. Compiled without /usr/X11R6/include, everything
works OK?!??!

However, PLIB doesn't *need* any files from /usr/X11R6/include - so for now I'm committing
your change but with the offending line commented out - until we can figure WTF is going on.

-- 
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] Any resolution on the license?

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

Norman Vine wrote:
> 
> Paul Bleisch writes:
> >
> >I think I read all of the messages about changing the
> >license for use in embedded things (consoles, etc...),
> >but I don't recall what the final outcome of that
> >discussion was.

> Not sure I ever really weighed in so
> 
> FWIW
> I believe that if we ever want PLib to become a standard
> we need a license that will allow 'commercial' interests to
> feel comfortable.

A *standard*...Wow!

I only ever intended PLIB to be something that enough people
would find useful that it would encourage a few more games
writers to make Linux versions.  At that it's successful -
I have no pretensions of it ever becoming another OpenGL or
X/Motif!

No, I don't think PLIB will ever become a standard.  SDL and
CrystalSpace will probably grab that dubious honor.



Commercial interests have to come to terms with LGPL because
it's evident that the reverse is unlikely to be the case.

The company I work for decided to step back and consider
the issue and make a ruling.  Once that ruling is made,
we programmers know where we stand with using libraries
and development tools that are under each of the 'common'
OpenSource licenses.

IMHO, you have to be either 'in' or 'out' of the GPL world.

* If you are 'out', you shouldn't even try to use LGPL'ed
  stuff - don't harass the package maintainers to change
  - just accept that it's the rules of your organization.

* If you are 'in' then you need to get *WAY* in and your
  organization needs to know that you *WILL* be giving
  away small chunks of code to your competitors on some
  occasions - but that the anticipated return through
  not having to write this stuff yourself makes up for
  that.  You'll have to come to terms with the requirement
  that your customers have the theoretical right to
  relink your code against new versions - and if those
  are not .so/.DLL then you have some other corporate
  culture things to deal with.  This is something that
  your management have to know about - don't try to
  do this by the back door.

In the case of my organization, it wasn't a hard call
at all.  We build one-off flight simulators (well,
almost one-off) - and we quite often ship the complete
source code to our customers (under NDA).  Compared to
the trust that entails, LGPL is a walk in the park.

Console games are about as far down the other end of
the spectrum as I could imagine!

-- 
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] Any resolution on the license?

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

> Dave McClurg wrote:
> 
> i was in favor of leaving the license as LGPL and placing NDA calls outside plib
> using function overrides or hooks.  this keeps the plib project flexible and
> improving.  i also don't think the developer is responsible for supplying the
> end-user with the compilation tools and SDKs.

That's certainly true.

>  it that was true, much opensource would be in trouble.  if someone can explain
> why this approach does not comply with the terms of the LGPL in spirit and law,
> i would appreciate it.  i'm doing console development using plib.

I think that this is perfectly acceptable - and the very fact that you have
contributed so much to PLIB that you might not have done if it wasn't under
LGPL shows the value of the license.

Since I havn't signed the Sony NDA, I obviously don't know anything about the
specific nature of the secret API's.  That is the crux of this issue:

  * If the Sony API's can be made to look enough like OpenGL or other base
    libraries that PLIB uses such that PLIB does not have to be modified
    in order to make it work with those API's - then we don't have a problem.

  * If those API's cannot be made to look enough like OpenGL (or whatever) and
    you have to hack PLIB - then you'd have to find a way to make the changes
    to PLIB without including anything that SONY would find objectionable. Then
    you could publish these cryptic changes that none of the rest of us would
    understand - but which would be conditionally compiled out for everyone
    not developing for PS-2.

The only other thing you'd have to do to obey the LGPL is to tell your customers
where to get PLIB in the unlikely event they should ever wish to rebuild
their console game using a new version.  That's silly, I know - but it's
the rule.  You could put that in teeny-tiny letters in the manual or probably
even on your official web site.

  * If you feel you cannot even do *that* and you need to show revealing things
    about Sony's oh-so-secret stuff in order to get PLIB to work - then you
    are truly screwed.  Throw $10,000 in my direction and I'll write you a new
    private version that's utterly free of restrictions...that's negotiable!  :-)

> BTW: someone on opengl-gamedev posted this link for opengl on the PS2 console:
> http://www.dataplus.co.jp/OpenGL4ps2.html

Yep - interesting.  I'm guessing that some people want to use a *different* API
(maybe a lower level one) - and that's the problem for them.


Dave:

  Is there a way for you to share your NDA-limited "function overrides or hooks" with other
PS-2 console users?   I know you couldn't reveal them to (for example) me - because I
have not signed the PS-2 NDA - but to other developers perhaps?   It would be nice for
there to be a standard version of those things so that:

a) They didn't have to be re-invented.

b) PS-2 developers wouldn't have to worry that they were
   doing something unacceptable either to the PLIB community
   or to SONY.

c) I could even write a note to go into the PLIB README
   saying that I felt this was appropriate usage and
   not contrary to the spirit of the LGPL or my intended
   interpretation of it in the context of PLIB.

-- 
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] Any resolution on the license?

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

Paul Bleisch wrote:
> 
> I think I read all of the messages about changing the
> license for use in embedded things (consoles, etc...),
> but I don't recall what the final outcome of that
> discussion was.

There were two things that struck me:

* Two significant contributors indicated that they didn't
  want to change the license - and since I can't (and
  wouldn't) replace their contributions, the licence
  cannot be changed even if I personally wanted it to
  change.

* Since Dave is actually using PLIB on a console himself
  and is a contributor who DOESN'T want to change the
  license - I really have to believe that there is a way
  to stick to the spirit and law of LGPL and still work
  on PS-2.

So, the conclusion was that the status quo reigns.

There was some discussion of using the REALLY ancient
versions of the separate libraries that were floating
around without a specific license before I bundled them
into PLIB and placed them under LGPL.  I have no objection
to people doing that (under US copyright law, I still retain
copyright on those versions and you'd have to get my
permission to use them - that permission is hereby granted)
- but I've checked everywhere I can think of and I don't have
copies of PUI, etc from that far back.

I don't really relish the idea of buggy old versions of
PUI (especially) from that era floating around on the web,
but so long as people know what they are doing and don't
do anything stoopid like setting up a non-licensed PLIB
in competition with the modern LGPL'ed version, I can live
with that.

-- 
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] Any resolution on the license?

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

RE: [Plib-devel] Any resolution on the license?Dave McClurg  writes:
  I'll quit being a roadblock
  I agree to whatever license change Steve wants to make.
  It will only make my life easier convincing management to let me use plib.

  thanks and sorry for the hassle,

  Hi Dave

  You weren't a hassle to me at least.

  I think that you made some very valid points

  That a part of me identifies very closely with.

  Cheers

  Norman

RE: [Plib-devel] Any resolution on the license?

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

I'll quit being a roadblock
I agree to whatever license change Steve wants to make.
It will only make my life easier convincing management to let me use plib.

thanks and sorry for the hassle,
-- Dave McClurg

> Paul Bleisch writes:
> >
> >I think I read all of the messages about changing the
> >license for use in embedded things (consoles, etc...),
> >but I don't recall what the final outcome of that 
> >discussion was.
> >
> >
> 
> Not sure I ever really weighed in so
> 
> FWIW
> I believe that if we ever want PLib to become a standard
> we need a license that will allow 'commercial' interests to 
> feel comfortable.
> 
> Cheers
> 
> Norman

RE: [Plib-devel] New Relesae - When ?

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

Steve Baker writes:
>
>Hmmm - I thought CygWin asserted 'WIN32' - so it would pick up 
><float.h>
>from the previous ifdef.  Oh well - evidently not.

Cygwin currently defines _WIN32
but PLEASE DO NOT USE this as a blanket discriminator

it would be fine for testing to include <float.h> 

but this would break things

#ifdef _WIN32
#include <windows.h>
#else 
#include <unistd.h>
#endif

Cheers

Norman

Re: [Plib-devel] New Relesae - When ?

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

Norman Vine wrote:

> I found 2 minor glitches which I should have seen before
> but I guess because I had made the changes in my local CVS
> copy they never surfaced till I tried a fresh tarball :-(.
> 
> 1)  sg.h --
> 
> Cygwin needs <float.h> also
> 
> following starts at ~line 15 sg.h
> 
> #ifdef BSD
> #include <float.h>
> #endif
> #ifdef __MWERKS__
> #include <float.h>
> #endif
> #ifdef WIN32
> #include <float.h>
> #endif
> #ifdef __CYGWIN__
> #include <float.h>
> #endif

Hmmm - I thought CygWin asserted 'WIN32' - so it would pick up <float.h>
from the previous ifdef.  Oh well - evidently not.

That change is in CVS now.
 
> 2) the autoconfig configure stuff needs a little reworking
>     for Cygwin  -- I am working on this,
>     will follow up in another message.

OK - thanks.

-- 
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] Any resolution on the license?

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

Paul Bleisch writes:
>
>I think I read all of the messages about changing the
>license for use in embedded things (consoles, etc...),
>but I don't recall what the final outcome of that 
>discussion was.
>
>

Not sure I ever really weighed in so

FWIW
I believe that if we ever want PLib to become a standard
we need a license that will allow 'commercial' interests to 
feel comfortable.

Cheers

Norman

RE: [Plib-devel] Any resolution on the license?

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

i was in favor of leaving the license as LGPL and placing NDA calls outside
plib using function overrides or hooks.  this keeps the plib project
flexible and improving.  i also don't think the developer is responsible for
supplying the end-user with the compilation tools and SDKs.  it that was
true, much opensource would be in trouble.  if someone can explain why this
approach does not comply with the terms of the LGPL in spirit and law, i
would appreciate it.  i'm doing console development using plib.

BTW: someone on opengl-gamedev posted this link for opengl on the PS2
console:
http://www.dataplus.co.jp/OpenGL4ps2.html

--Dave McClurg

> I think I read all of the messages about changing the
> license for use in embedded things (consoles, etc...),
> but I don't recall what the final outcome of that 
> discussion was.
> 
> 
> Thanks,
> Paul

[Plib-devel] Any resolution on the license?

[Paul B. <pbl...@di...>]

I think I read all of the messages about changing the
license for use in embedded things (consoles, etc...),
but I don't recall what the final outcome of that 
discussion was.


Thanks,
Paul

[Plib-devel] SUNWspro patch, questions

[Loring H. <ls...@cs...>]

I sent the following to plib-users over a week ago and haven't gotten a
reply, I think because it should have gone to plib-devel.

Loring

RE: [Plib-devel] New Relesae - When ?

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

Steve Baker writes:
>
>> >OK - PLIB 1.1.12 is out on the usual web site - check it
>> >out.
>> >     http://plib.sourceforge.net
>

I found 2 minor glitches which I should have seen before
but I guess because I had made the changes in my local CVS
copy they never surfaced till I tried a fresh tarball :-(.

1)  sg.h --

Cygwin needs <float.h> also

following starts at ~line 15 sg.h
 
#ifdef BSD
#include <float.h>
#endif
#ifdef __MWERKS__
#include <float.h>
#endif
#ifdef WIN32
#include <float.h>
#endif
#ifdef __CYGWIN__
#include <float.h>
#endif


2) the autoconfig configure stuff needs a little reworking
    for Cygwin  -- I am working on this,  
    will follow up in another message.

FWIW
except for the <float.h> irritation the current FGFS development tree
seems to work just fine with this release of PLib :-))

Cheers

Norman

Re: [Plib-devel] New Relesae - When ?

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

Norman Vine wrote:

> FWIW
> We are about to get a new FlightGear out the door to.
> Maybe next time we are ready for a PLib release
> we should coordinate and release simultaneously

Yep - it would be nice to get PLIB 1.2.0 out in time for
both FGFS *and* my upcoming TuxKart release.  TuxKart is
going to *require* PLIB 1.1.12 or better because I moved
some code out of TuxKart and into SG.

-- 
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] New Relesae - When ?

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

Steve Baker writes:
>
>Norman Vine wrote:
>
>> >OK - PLIB 1.1.12 is out on the usual web site - check it
>> >out.
>> >     http://plib.sourceforge.net
>
>> I am compiling it now :-)
>
>Since it's nearly 3am - I'm going to bed *before* you have
>a chance to find anything wrong.  :-)
>

No fears I won't get to FGFS till tonight. :-)

FWIW
We are about to get a new FlightGear out the door to.
Maybe next time we are ready for a PLib release
we should coordinate and release simultaneously

Thanks again

Norman

Re: [Plib-devel] New Relesae - When ?

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

Norman Vine wrote:

> >OK - PLIB 1.1.12 is out on the usual web site - check it
> >out.
> >     http://plib.sourceforge.net

> I am compiling it now :-)

Since it's nearly 3am - I'm going to bed *before* you have
a chance to find anything wrong.  :-)

-- 
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] New Relesae - When ?

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

Steve Baker writes:
>> 
>> Norman Vine wrote:
>> >
>> > A 1.1.xx release would satisfy my requirement that
>> > the library is downloadable as a package and not
>> > only available through CVS.
>> 
>> OK - I'm about ready to release what's in CVS right
>> now as 1.1.12 - perhaps you could check it out with
>> FGFS.
>
>OK - PLIB 1.1.12 is out on the usual web site - check it
>out.
>     http://plib.sourceforge.net
>

Thanks Steve,

I am compiling it now :-)

Norman

Re: [Plib-devel] New Relesae - When ?

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

Steve Baker wrote:
> 
> Norman Vine wrote:
> >
> > A 1.1.xx release would satisfy my requirement that
> > the library is downloadable as a package and not
> > only available through CVS.
> 
> OK - I'm about ready to release what's in CVS right
> now as 1.1.12 - perhaps you could check it out with
> FGFS.

OK - PLIB 1.1.12 is out on the usual web site - check it
out.
     http://plib.sourceforge.net

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

Re: [Plib-devel] New Relesae - When ?

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

Norman Vine wrote:
>
> A 1.1.xx release would satisfy my requirement that
> the library is downloadable as a package and not
> only available through CVS.

OK - I'm about ready to release what's in CVS right
now as 1.1.12 - perhaps you could check it out with
FGFS.

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