plib-devel

[Plib-devel] [Fwd: [TuxKart-users] I have a compilation problem]

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

Steve Baker wrote:
> 
> al wrote:

> Mandrake 7.1
> Glide_V3-2.60.15-3mdk.rpm & devel rpm
> Mesa3.2(compiled from source)
> plib-1.2.0-i586.rpm (NOT source)
> freeglut-alpha-1.3(source)
> VooDoo3 1000 AGP

...

> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use this function)

...

This seems to be related to the problem with FLT_EPSILON being undefined in some
places and <float.h> being "missing" sometimes.

Dunno if anyone can shed any light on this - but indeed, the classic C header
"/usr/include/float.h" is not present under my SuSE 6.4 system...and none of
the other headers in /usr/include or and of it's subdirectories seem to have
a definition for FLT_MAX.

In desperation, I wrote:

#include <math.h>

float x = FLT_MAX ;

...and ran:

  % cpp test.c

...which suggested that the definition of FLT_MAX was in

   "/usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h"

A SuSE specific directory?!?  Yuck!

Can *anyone* tell me why this might be fouling up under
Mandrake 7.1?

The first couple of lines of /usr/include/plib/sg.h are:

  #include <limits.h>
  #include <math.h>

I've had to avoif doing a:

  #include <float.h>

...under Linux *because* that file has ceased to exist in the 'normal' places.

My head hurts...somebody make it stop!

There must be some weird kind of magic going on inside the compiler
somewhere.

-- 
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] RE: Model Formats

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

Ben Woodhead wrote:
> 
> Hello
> 
> Thanks for your help Dave and Steve. You are right I did know about ssg and
> ac3d, and I was looking to find if any of the new types where implemented.
> Know I can find a modeler for these formats.
> One think is there any other modelers around that support ssg format other
> then pretty poly.

No - nothing else will support '.ssg' format - that is something that is
unique to PLIB's SSG module.  PrettyPoly supports it only because it
happens to use SSG - so it was easy.

SSG was never intended to be an 'export' file format - but it is the
best format to build models in PPE initially since it guarantees to
save every single flag and option EXACTLY as you modelled it.  Every
other format will have odd missing things or subtle errors in conversion.

If you happen to use PrettyPoly for modelling *and* PLIB/SSG for rendering
in your application, then you'll get perfect WYSIWYG since the model will
for sure look the same in the modeller as it does in your application.

-- 
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] RE: Model Formats

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

Hello 

Thanks for your help Dave and Steve. You are right I did know about ssg and
ac3d, and I was looking to find if any of the new types where implemented.
Know I can find a modeler for these formats.
One think is there any other modelers around that support ssg format other
then pretty poly.

Thanks Ben

RE: [Plib-devel] TuxKart.

[Vallevand, M. K <Mar...@UN...>]

Great.

I'll make a Windows version tonight, if I have time.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

> 
> FYI:  I just released the first release of TuxKart - which 
> uses PLIB and
> the same characters as my Tux_AQFH game.
> 
>      http://tuxkart.sourceforge.net
> 
> Have fun!
> 
> -- 
> Steve Baker 

RE: [Plib-devel] Model Formats

[Dave M. <dp...@ef...>]

> Dave McClurg wrote:
> > 
> > Steve wrote:
> > > Annoyingly, the current need is to be able to import models built
> > > in Blender - this would be very useful for the guys who want to
> > > build models for TuxKart under Linux.
> > >
> > > The snag appears to be (although I'm not a blender expert) that it
> > > only exports DXF (no texture - yuk!) and VRML (not supported under
> > > PLIB - ack!)
> > >
> > Interesting...  I wanted to do a "#VRML V1.0 ascii" loader for 
> PLIB a while
> > back with the specific goal of importing models created in blender.
> > End-users can grab a free copy of blender and create models for 
> our games.
> > If that makes sense to you as well, I'll put some work into it 
> and see what
> > happens.
> 
> Yes - that would be very useful.  I wonder what kind of a subset
> of VRML blender actually produces?  A totally general VRML loader
> is quite a big deal.
> 

I grabbed the latest blender (version 1.8) and the tutor files.  I
exported the spider2 and teapot models as "wrl" files (VRML 1.0).

I then built the "VRML 1.0 syntax checker" from the DIVE toolkit
which syntax checks VRML 1.0 files.  After a couple minor tweaks to
the grammar for trailing commas and empty lists, the syntax checker
successfully parsed spider2.wrl and teapot.wrl !

I looked at the wrl files and AFAICT adding semantic actions to the
parser to capture the necessary information for SSG should be *very*
do-able.  Blender spits out Coordinate3 lists followed by an
IndexedFaceList.  Looks easy enough to follow and should work well
with Mark's ssgVertexArray.cxx module.

I think I now have a clear path now to adding a VRML 1.0 loader to
SSG.  I'll try to kick it out this week.

-- Dave McClurg

Re: [Plib-devel] Model Formats

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

Dave McClurg wrote:
> 
> Steve wrote:
> > Annoyingly, the current need is to be able to import models built
> > in Blender - this would be very useful for the guys who want to
> > build models for TuxKart under Linux.
> >
> > The snag appears to be (although I'm not a blender expert) that it
> > only exports DXF (no texture - yuk!) and VRML (not supported under
> > PLIB - ack!)
> >
> Interesting...  I wanted to do a "#VRML V1.0 ascii" loader for PLIB a while
> back with the specific goal of importing models created in blender.
> End-users can grab a free copy of blender and create models for our games.
> If that makes sense to you as well, I'll put some work into it and see what
> happens.

Yes - that would be very useful.  I wonder what kind of a subset
of VRML blender actually produces?  A totally general VRML loader
is quite a big deal.

-- 
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] Model Formats

[Dave M. <dp...@ef...>]

Steve wrote:
> Annoyingly, the current need is to be able to import models built
> in Blender - this would be very useful for the guys who want to
> build models for TuxKart under Linux.
>
> The snag appears to be (although I'm not a blender expert) that it
> only exports DXF (no texture - yuk!) and VRML (not supported under
> PLIB - ack!)
>
Interesting...  I wanted to do a "#VRML V1.0 ascii" loader for PLIB a while
back with the specific goal of importing models created in blender.
End-users can grab a free copy of blender and create models for our games.
If that makes sense to you as well, I'll put some work into it and see what
happens.

Thanks,
--Dave

Re: [Plib-devel] Model Formats

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

Dave McClurg wrote:

> If someone has a specific use for an improved OBJ or ASE loader,
> please let me know.  The added motivation always helps.

Annoyingly, the current need is to be able to import models built
in Blender - this would be very useful for the guys who want to
build models for TuxKart under Linux.

The snag appears to be (although I'm not a blender expert) that it
only exports DXF (no texture - yuk!) and VRML (not supported under
PLIB - ack!) 

Another *cool* approach might be to write a blender plugin to
link in PLIB and hence read/write SSG or any of the other formats
we support.  Seems like the Blender guys should be interested
in that since they are short of file formats and we could get
them a bunch in very short order.

Does anyone out there know how to write blender plugins?

-- 
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] Model Formats

[Dave M. <dp...@ef...>]

Steve wrote:
> The AC3D and SSG loaders are not "old" - they work correctly and have
> texture support.

I'm sorry Steve.  Ben asked about "new" model loaders and I just wanted
to categorize the loaders according to age.  The AC3D and SSG loaders
are the oldest and therefore the most stable and tested.

> > I was looking for a list of model formats that ssg can load. At
> one point
> > Steve had mentioned that some new model type where added to the model
> > loading functions but I was unable to find any type of list to say which
> > ones.
>
> So far:
>
>   ASE SSG 3ds DXF TRI AC3D OBJ VRML
>
> Of these, I know that AC3D and SSG work well, I'm not so sure
> about the others because I don't use them much.
>
> Dave:
>
>   Can you comment?
>

The TRI loader was just a quicky I did because it was easy.  It is
the same TRI format that AC3D uses.  I think it comes from Wavefront.

The 3ds loader was created by Per Liedman.  It is a very important
*binary* format.  AFAIK, it works correctly and supports textures.
Per?

The DXF loader was adapted from John Burkardt's IVCON.  With
Wolfram Kuss' help I've updated it to support quads, polylines,
and MxN polymeshes.  It doesn't support textures, which are not
in the DXF specification, but it is a widely supported format
and a good way to import geometry into SSG.

The ASE loader is the one I wrote and use.  I have tested it and
feel confident that it works correctly.  It has texture support.
I'm willing to help anyone use it or improve it.  Any copy of MAX
has the source code for the ASE export plugin.  I'm working on
adding animation support which will require new SSG entities.

The OBJ loader was adapted from John Burkardt's IVCON.  I added
texture support after looking at how Andreas Umbach handled it
in gltron.  The Wavefront OBJ format is wonderfully simple and elegant.

http://www.cica.indiana.edu/graphics/object_specs/OBJ.format.txt

The "Nebula Device" project (http://www.radonlabs.de/) liked the
OBJ format so much they extended it and use the "n3d" extension.
But AFAICT, Wavefront OBJ lacks animation support.  Otherwise,
I would dump ASE and switch over to it.

I hope to cleanup and improve the OBJ loader soon so it can import
the object names and other things I missed the first time.  Also,
the exporter currently lacks texture support.

Many of these loaders have an exporter.  The exporter feature was
mainly needed for PPE (pretty poly editor).  If you want to *save*
a scene graph, you should use ssgSaveSSG() which supports all the
SSG entities.  Otherwise, you'll lose information.

Another *big* todo item is to add ssgIndexArray to the _ssgCreateFunc
so it can support Mark's ssgVertexArray.cxx module.  That would
make large ASE models load and render faster since they are
naturally in indexed array form.

If someone has a specific use for an improved OBJ or ASE loader,
please let me know.  The added motivation always helps.

--Dave McClurg

Re: [Plib-devel] Model Formats

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

Dave McClurg wrote:
> 
> here are the new loaders that were recently added to SSG:
> 
> - with texture support
> 
>         ssgLoadASE.cxx  -- 3dsmax ASE (ascii export) format
>         ssgLoadOBJ.cxx  -- wavefront OBJ format
> 
> - geometry only
> 
>         ssgLoadDXF.cxx  -- autodesk DXF
>         ssgLoadTRI.cxx  -- triangles format that matches AC3D triangle format
> 
> here are the old loaders
> 
>         ssgLoad3ds.cxx  -- Per Liedman's 3ds loader
>         ssgLoadAC.cxx   -- Steve Baker's AC loader
>         ssgLoadSSG.cxx  -- native SSG format
> 
>         ssgLoadVRML.cxx   -- doesn't work yet

The AC3D and SSG loaders are not "old" - they work correctly and have
texture support.

-- 
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] Model Formats

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

Ben Woodhead wrote:

> I was looking for a list of model formats that ssg can load. At one point
> Steve had mentioned that some new model type where added to the model
> loading functions but I was unable to find any type of list to say which
> ones.

So far:

  ASE SSG 3ds DXF TRI AC3D OBJ VRML 

Of these, I know that AC3D and SSG work well, I'm not so sure
about the others because I don't use them much.

Dave:

  Can you comment?

-- 
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] _ssgShareState bug

[Dave M. <dp...@ef...>]

regarding the bug in _ssgShareState() ... i can't reproduce the problem !?!?

i am using the latest PLIB from CVS and tux_aqfh-1.0.10.tar.gz from the
tux_aqfh
website.  then i commented back in the _ssgShareState() function

      //st = data -> st ;
      st = _ssgShareState ( data -> st ) ;

and with new ssg lib and new relinked tux_aqfh, i have no problems.  i even
traced
into the _ssgShareState() function and it seems to be working.  This is
under win32.

perhaps i forgot what the bug was.  didn't it crash tux_aqfh right away?

thanks,
-- Dave McClurg

RE: [Plib-devel] Model Formats

[Dave M. <dp...@ef...>]

here are the new loaders that were recently added to SSG:

- with texture support

	ssgLoadASE.cxx	-- 3dsmax ASE (ascii export) format
	ssgLoadOBJ.cxx	-- wavefront OBJ format

- geometry only

	ssgLoadDXF.cxx	-- autodesk DXF
	ssgLoadTRI.cxx	-- triangles format that matches AC3D triangle format

here are the old loaders

	ssgLoad3ds.cxx	-- Per Liedman's 3ds loader
	ssgLoadAC.cxx	-- Steve Baker's AC loader
	ssgLoadSSG.cxx	-- native SSG format

	ssgLoadVRML.cxx   -- doesn't work yet

> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...]On Behalf Of Ben Woodhead
> Sent: Tuesday, July 04, 2000 7:00 AM
> To: pli...@li...
> Subject: [Plib-devel] Model Formats
> 
> 
> Hello everybody
> 
> I was looking for a list of model formats that ssg can load. At one point
> Steve had mentioned that some new model type where added to the model
> loading functions but I was unable to find any type of list to say which
> ones. 
> 
> Thanks Ben

[Plib-devel] Model Formats

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

Hello everybody

I was looking for a list of model formats that ssg can load. At one point
Steve had mentioned that some new model type where added to the model
loading functions but I was unable to find any type of list to say which
ones. 

Thanks Ben

[Plib-devel] TuxKart.

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

FYI:  I just released the first release of TuxKart - which uses PLIB and
the same characters as my Tux_AQFH game.

     http://tuxkart.sourceforge.net

Have fun!

-- 
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] ANNOUNCING PLIB 1.2.0 and 1.3.0.

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

ANNOUNCING PLIB 1.2.0 and 1.3.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is one of those rare occasions when there is nothing significantly
new in the release - but we are incrementing the version number to indicate
stability.

Both PLIB 1.2.0 and 1.3.0 are essentially identical to 1.1.12.

From today onwards:

  1.0.xx is officially obsolete - please don't use it, rely on it
         or distribute it.  If you find an application that needs
         it, please ask the author to upgrade.

  1.1.xx is also officially obsolete - same deal.

  1.2.0  is the new 'stable' release, it's feature set is frozen and
         there won't be a 1.2.1 unless we have to fix a critical bug.
         This is the "known good" version that Linux distro's should
         ship, application developers should build against and users
         should download.

  1.3.0  is the first of the new 'experimental' versions - that's where all
         the cutting edge new development will be done, new features will
         be added - new bugs also.  Ultimately there will be a 1.4.0 which
         will once again be stable.

Thanks to the many people who helped to push 1.2.0 screaming and
kicking into the world.  There is no great glamor in working on PLIB
- but several quality projects would not be where they are without your
help.

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

"Curtis L. Olson" wrote:

> > ...I can't understand why that should possibly be. Compiled without /usr/X11R6/include, everything
> > works OK?!??!
> 
> Sounds like you must have an older version of plib in /usr/X11R6
> ... now wouldn't that be funny. :-)

Well, I did check in there - I couldn't find anything with a clashing filename.
 
> I have seen more complicated apps like FlightGear start to develop
> sensitivities with link orders.

Yep - I guess that could be.

-- 
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] Are we ready for 1.2.0?

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

> A.  OK.  Release immediately.

--Dave McClurg

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

Thanks for the thoughtful replies Steve.

I'm glad you want to stick with the LGPL.  I really support opensource
development as a better *process* and I think the LGPL is the best license
to encourage use and development of opensource libraries.

Because of PLIB's design, it has few dependencies and only requires an
OpenGL api to run.  For the PS2 you can start using the alpha-ware OpenGL
from DataPlus (http://www.dataplus.co.jp/OpenGL4ps2.html) or write your own
subset OpenGL (quake basically took this approach with MiniGL).

To write your own PS2 OpenGL subset look at TinyGL
(http://www-stud.enst.fr/~bellard/TinyGL.html).  It is a great starting
point.  It has a zlib-like license which permits you to incorporate it into
commericial proprietary code.

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

sure.  i would love to.

For my own project, I have a LGPL library that hides platform dependencies
and presents PLIB with a subset of GLUT/OpenGL.
http://www.pond.net/~davem/tinylib/.  What I'm doing for console is creating
a closed-source implementation of TinyLIB interfaces (allowed and encouraged
for others too).

Win32 TinyLIB is feature complete.  On PS2, we have most of GLUT and about
30% of OpenGL finished (we can run the classic GEARS opengl example on the
PS2).  If you're interested in following this approach and have a signed PS2
NDA, perhaps we can join forces.

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

Both technically and legally, I don't see how developing for Sony PS2 using
an LGPLed PLIB presents a problem.

-- Dave McClurg

RE: [Plib-devel] Are we ready for 1.2.0?

[Vallevand, M. K <Mar...@UN...>]

A.  OK.  Release immediately.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

Re: [Plib-devel] SUNWspro patch, questions

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

Steve Baker writes:
> > 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*!

Yes this part about handling dependencies is definitely a black art
and they've gone to great lengths to hide it from even the developers
who use automake/autoconf.

> It seems that with this line in configure.in:
> 
>        CPPFLAGS="$CPPFLAGS -I$x_includes"

Hmmm, I'm surprised you even got away with this.  I've seen this sort
of thing break different versions of Make which didn't like the
circular reference.

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

Sounds like you must have an older version of plib in /usr/X11R6
... now wouldn't that be funny. :-)

I have seen more complicated apps like FlightGear start to develop
sensitivities with link orders.

No idea if either of these are related, but they are the first things
that come to mind.

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] Are we ready for 1.2.0?

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

Steve Baker writes:
>
>Well, 1.1.12 has been out for a few days now - and apart from a few
>build issues on the more oddball platforms, I've not had any 
>complaints.
>
>Are we ready to call this 1.2.0 with all the attendant implications
>of stability and feature-freeze that goes along with that?

The only thing I can think of is that the configure.in
script could use some cleaning up but it seems to have been
working as is so this shouldn't be a reason to hold up a release.

Therefore barring any reports of show stoppers

I vote for

>   A)  OK  release 1.2.0 immediately.

Many thanks again to all those who have contributed :-)

Norman

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

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

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

Steve Baker writes:
> 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

Actually I went through the whole procedure and got OpenGL running
accelerated in a window with my Voodoo3 when I first got it.  All I
did this time was replace the libGL.so with one built from the latest
cvs-mesa, and it didn't accelerate.  I removed the new libGL, and move
the old one back in place, and everything ran accelerated again as
before.

> 2) Either make sure that /dev/3dfx is installed and has rw-rw-rw
>    permissions...or run your application as 'root'.

This is no longer a requirement with the XF-4.0 / dri stuff.  But the
instructions for getting this all to work are either non-existant, or
old and extremely misleading ... or perhaps I just haven't stumbled
across the secret hiding place of the real, informative directions?

> 3) Don't demand stuff like stencil planes, alpha planes, etc.
>    If you let GLUT pick the defaults you should be OK.

As I said, applications run great with my current libGL.so ... but not
with the new one I just built.  So there is something additional that
I need to figure out with building a XF86-4.0 / DRI compatible
libGL.so.

> 4) Don't forget to "setenv MESA_GLX_FX fullscreen".

Hmmm, perhaps the libGL.so could be tricked into running like a
voodoo-1/2 mode with this, but the whole point of my buying a Voodoo-3
was so I could have accelerated opengl in a window. :-)

> 5) Use 'ldd' to ensure your application is getting the libGL.so
> 6) Use ldd to ensure that libGL.so is demanding libglide.so.

Actually libglide3.so in this case ...

> Does this latest version *have* to use DRI?

The latest of version of Mesa doesn't *have* to use DRI ... not at
all.  But, that is what I'd like to get working here.

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

I've been continually surprised by the complete lack of documentation
with all of this new XF86-4.0 dri stuff.  I find basically nothing
useful ... the stuff I have found is full of old, outdated, misleading
info such as saying /dev/3dfx is still required which it no longer is.

I have no problem reading directions and trying to figure things out
first for myself, but I'm flying blind here.  I've seen some pretty
low-end open-source projects documented a *lot* better than this
... which has all sorts of commercial tie ins.  I appreciate the work
everyone has invested to get 3d working better under linux, but the
documentation problem is completely inexcusable.

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] Are we ready for 1.2.0?

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

Well, 1.1.12 has been out for a few days now - and apart from a few
build issues on the more oddball platforms, I've not had any complaints.

Are we ready to call this 1.2.0 with all the attendant implications
of stability and feature-freeze that goes along with that?

If so, I'll make a release of it and we'll start two parallel
threads:

  1.2.xx  -- Bug fixes to 1.2.0 only.

  1.3.xx  -- New features.

Please vote:

   A)  OK  release 1.2.0 immediately.

   B)  NO  I need new features in 1.1.xx before we go to 1.2.0

   C)  NO  I need more time for testing (or there are too many bugs)
           so please wait for a while longer (or make a 1.1.13 first).

If there is a majority for (A) within (say) 48 hours, I'll make 1.2.0,
if not I'll wait.

New features due immenently (but not yet ready for 1.2.0) include:

* New loaders/writers,
* The FGFS Line-of-Sight code
* Curt's new Sky model.

We'd have to delay at least a month to get those into 1.2.0  IMHO.

My vote is (A) because I'd like TuxKart to be released with 1.2.0
and I want to do that within the next couple of weeks.

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

> > 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? :-)

Probably not - I'm a hopeless speller - but if people put it
down to British spelling that's fine by me!

  C-O-L-O-U-R
  Z is pronounced 'Zed' not 'Zee'.

Americans only say 'Zee' to make the Alphabet song rhyme. :-)


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

Well, that's good - but I'd like to know WHY this weird stuff happens.  If there is something
in /usr/X11R6/include that screws up some PLIB symbol, I'd like to know about it because
there will be applications programs that need to include both X11 *and* PLIB headers and we
don't want any nasty suprises!

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