plib-users

Re: [Plib-users] plib for a game engine..

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

> I was also wondering what the general differences are between plib and
> crystal space. (e.g. what advantages does plib have over CS?)
>

plib is simple, stable, easy to learn, and has actually been used to make
several games.

CS is interesting, feature rich, popular, somewhat unstable (last i
checked), and not very useful.

if you just want to study a 3d engine, you can learn alot from CS but if you
want to build a game, you will have better luck with plib.  look at TuxKart,
TuxAQFH, or the other links on http://plib.sourceforge.net

--Dave

[Plib-users] plib for a game engine..

[<ha...@sl...>]

I'm designing a 3D RPG and am considering plib as the one of the options
for a 3D library.

I'm wondering if there is currently any mechanism to convert or load
worlds from any of the decent game editors (worldcraft, quake editor,
etc).

I was also wondering what the general differences are between plib and
crystal space. (e.g. what advantages does plib have over CS?)

Two differences I've noticed are:
1) plib looks *much* simpler with a much smaller learning curve than
   crystal space.
2) plib provides tree based rendering and culling, where crystal space
   focuses on a "portal engine" for performance.  Does this theoretically
   make plib perform better than crystal space in an open area scene,
   while CS performs better in a closed quake-style engine?
3) crystal space has more functionality:
     *      a decent software renderer
     *      more file loaders

thanks,
Brian Hayward

Re: [Plib-users] *.mdl-loader for Microsoft flight-simulator

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

Michael Wessels wrote:
> 
> Dear Steve,
> 
> I have downloaded the latest Win-binary of ppe. But I get the error, that
> *.mdl files are not recognized by the loader, when I tried to open a *.mdl
> file.
> May be I have to wait for a new Win-binary version of ppe ?

The MDL loader is in the PLIB library - and currently only in an unreleased
version.  To get that you need to download the PLIB sources from the CVS
repository on SourceForge.

Once you have that, you'll need to compile and install it - then download the
PPE sources - then recompile and install those.  PPE is also unreleased - so
again, you need the CVS archives.

You may gather that this is all fairly new stuff!

We should be releasing a new 'official' PLIB sometime this month - but PPE is
far from ready for an actual user release.  Hence you are doomed to needing
CVS snapshots for the immediate future.

> Concerning my flight sim I have not finished the work which I want to do for
> the first release and which could be published as shareware.

  "Release early, Release often" is the OpenSource developer's credo...but YMMV.

> I hope to finish this work in the next three months. I will write also a
> web-page. It would than very nice, to make a link from the plib-page to my
> web-page.

OK - let me know when you have something.  Does this project have a name?
 
> The main ideas of my flight sim is the dynamics simulation of the aircraft and
> to have the possibilities by a GUI to change the main relevant aircraft
> parameters.

I think that's a goal of FGFS also.
 
> The work progress is not so quick, because I only can work on this project as
> a hobby beside my other daily works.

Yep - I think we can all identify with that view!
 
-- 
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-users] *.mdl-loader for Microsoft flight-simulator

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

Michael wrote:

>Dear Steve,
>
>I have downloaded the latest Win-binary of ppe. But I get the error, that
>*.mdl files are not recognized by the loader, when I tried to open a *.mdl
>file.
>May be I have to wait for a new Win-binary version of ppe ?

Yes, the binary was too old. The *.mdl-loader is quite new. I just
uploaded the newest Windo$-binary, it should work now.

What compiler do you use? 

BTW, to get you started, here is a small snip from a post of mine on
the fgfs-list:
------------------
I had a look in flightsim.com for planes for fgfs. AFAIK, fgfs models
the Cessna 172, the X-15 and the Navion (which Navion, the Super
260?). The following files work with the newest plib from cvs:

file name          looks       legal status
x15mplay.zip       v.good        ?    
x15.zip            good-v.good   ?    

navonfs6.zip       good-ok       ?          
navion97.zip       v.good        ?        

c172-ast.zip       v.good       (1)        
n7572698.zip       v.good     Freeware(?)  
osu172jt.zip       v.good        ?          
----------------------

There are thousands of planes on www.flightsim.com.
The newer ones dont work so well, try the ones for fsfw95, for
example the Dolphin or the SE5. Currently, you have to input 
the texture path before you load a model. This should change VERY soon
:-). I will then send you a new exe as an E-Mail.

BTW, if you have a 3-button mouse, press the middle one and 
drag the mouse :-).

>Michael

Bye bye,
Wolfram.

Re: [Plib-users] *.mdl-loader for Microsoft flight-simulator

[Michael W. <michael.wessels@z.zgs.de>]

Dear Steve,

I have downloaded the latest Win-binary of ppe. But I get the error, that
*.mdl files are not recognized by the loader, when I tried to open a *.mdl
file.
May be I have to wait for a new Win-binary version of ppe ?

Concerning my flight sim I have not finished the work which I want to do for
the first release and which could be published as shareware.
I hope to finish this work in the next three months. I will write also a
web-page. It would than very nice, to make a link from the plib-page to my
web-page.

I know the flight-gear project.

The main ideas of my flight sim is the dynamics simulation of the aircraft and
to have the possibilities by a GUI to change the main relevant aircraft
parameters.

The work progress is not so quick, because I only can work on this project as
a hobby beside my other daily works.

Michael


Steve Baker schrieb:

> Michael Wessels wrote:
> >
> > Hi all,
> > there is a *.mdl loaderin PLIB, as Steve Baker has said.
> > My question is now, who has used this loader and if this person can give
> > me  his example( the used mdl-file) and also his experiences (what is
> > about the textures ?)
>
> The simplest way to try it out is to download PrettyPoly (which will load
> MDL files using the PLIB loader).
>
> Then you can look at the model visually - and also with the structure
> diagram viewer.
>
> > I have programmed a flight simulator using PLIB and I am interesting to
> > use Microsoft Flight Simulator aircrafts.
>
> Cool!  Is this flight sim of yours freeware?   Can we download a copy?
> If so, do you want me to put a link to it from the main PLIB site?
>
> Have you looked at FlightGear?   www.flightgear.org
>
> --
> 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-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

Re: [Plib-users] *.mdl-loader for Microsoft flight-simulator

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

Michael Wessels wrote:
> 
> Hi all,
> there is a *.mdl loaderin PLIB, as Steve Baker has said.
> My question is now, who has used this loader and if this person can give
> me  his example( the used mdl-file) and also his experiences (what is
> about the textures ?)

The simplest way to try it out is to download PrettyPoly (which will load
MDL files using the PLIB loader).

Then you can look at the model visually - and also with the structure
diagram viewer.

> I have programmed a flight simulator using PLIB and I am interesting to
> use Microsoft Flight Simulator aircrafts.

Cool!  Is this flight sim of yours freeware?   Can we download a copy?
If so, do you want me to put a link to it from the main PLIB site?

Have you looked at FlightGear?   www.flightgear.org

-- 
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-users] *.mdl-loader for Microsoft flight-simulator

[Per L. <li...@ho...>]

> Hi all,
> there is a *.mdl loaderin PLIB, as Steve Baker has said.
> My question is now, who has used this loader and if this 
person can give
> me  his example( the used mdl-file) and also his 
experiences (what is
> about the textures ?)
> I have programmed a flight simulator using PLIB and I am 
interesting to
> use Microsoft Flight Simulator aircrafts.

There is a modified version of tux_example that uses the 
MDL loader here:

   http://www.mdstud.chalmers.se/~md6pl/LoadTest.cxx

Put the model and its textures in the working directory and 
give the model name as an argument on the command line. You 
can use the keys G, F and ' to toggle gear, flaps and 
spoilers on and off.

It would be interesting to see your flight simulator! Is 
there a homepage?

Good luck,
Per Liedman

[Plib-users] *.mdl-loader for Microsoft flight-simulator

[Michael W. <michael.wessels@z.zgs.de>]

Hi all,
there is a *.mdl loaderin PLIB, as Steve Baker has said.
My question is now, who has used this loader and if this person can give
me  his example( the used mdl-file) and also his experiences (what is
about the textures ?)
I have programmed a flight simulator using PLIB and I am interesting to
use Microsoft Flight Simulator aircrafts.


Michael

Re: [Plib-users] *.msd-loader for Microsoft flight simulator aircrafts

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

Michael Wessels wrote:

> I have red in PPE-news the following:
> 
> Also there is a new *.mdl-loader for Microsoft flight-simulator
> aircraft.
> 
> Question:
> Is there  a loader for *.mdl-files also in plib available?

Yes - just grab the CVS version of PLIB and you'll see it there.

All of PPE's loaders and writers come with PLIB - but we are not
yet ready to make a new PLIB release.

The MDL loader still seems to have *some* problems - because the
file format isn't too well documented and it's quite complex.

-- 
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-users] *.msd-loader for Microsoft flight simulator aircrafts

[tjones <tj...@is...>]

I am pretty sure that the loader is actually in plib and is being used by
ppe.

Later Ben
----- Original Message -----
From: Michael Wessels <michael.wessels@z.zgs.de>
To: <pli...@li...>
Sent: Thursday, November 02, 2000 4:26 PM
Subject: [Plib-users] *.msd-loader for Microsoft flight simulator aircrafts


> Hi all,
> I have red in PPE-news the following:
>
> Also there is a new *.mdl-loader for Microsoft flight-simulator
> aircraft.
>
> Question:
> Is there  a loader for *.mdl-files also in plib available?
>
> Michael
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>
>

[Plib-users] *.msd-loader for Microsoft flight simulator aircrafts

[Michael W. <michael.wessels@z.zgs.de>]

Hi all,
I have red in PPE-news the following:

Also there is a new *.mdl-loader for Microsoft flight-simulator
aircraft.

Question:
Is there  a loader for *.mdl-files also in plib available?

Michael

[Plib-users] Re: plib-users digest, Vol 1 #140 - 3 msgs

[Kevin G. <av...@cu...>]

First, apologies for replying to the digest.

pli...@li... wrote:

> Send plib-users mailing list submissions to
>         pli...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.sourceforge.net/mailman/listinfo/plib-users
> or, via email, send a message with subject or body 'help' to
>         pli...@li...
>
> You can reach the person managing the list at
>         pli...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of plib-users digest..."
>
> Today's Topics:
>
>   1. Re: Loading AC Models and Textures (Wolfram Kuss) (Kevin Glass)
>   2. Re: Re: Loading AC Models and Textures (Wolfram Kuss) (Steve Baker)
>   3. R: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss) (Paolo Leoncini)
>
> --__--__--
>
> Message: 1
> Date: Mon, 30 Oct 2000 21:16:07 +0000
> From: Kevin Glass <av...@cu...>
> Organization: Netscape Online member
> To: pli...@li...
> Subject: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss)
> Reply-To: pli...@li...
>
> >
> > Today's Topics:
> >
> >   1. Re: Loading AC Models and Textures (Wolfram Kuss)
> >
> > -- __--__--
> >
> > Message: 1
> > From: Wolfram Kuss <w_...@rz...>
> > To: pli...@li...
> > Subject: Re: [Plib-users] Loading AC Models and Textures
> > Date: Sun, 29 Oct 2000 20:12:54 +0000
> > Organization: Hammes SW
> > Reply-To: pli...@li...
> >
> > Kevin wrote:
> >
> > >Sometimes I get warnings when loading the models saying that the
> > >textures can not be found. However, this does not happen consistantly.
> > >When I do get these messages, the directories being used are not the
> > >directory I set with model and texture path.
> >
> > Strange. Which directories do the error messages name and which do you
> > use?
>
> The error messages (when they do show up) pertain to the current directory,
> or rather, where I run it from. Its as though the texture path is just
> ignored.
>
> >
> >
> > >I'm using VC6.0 on Win98. The code is threaded using the pthread
> > >library, could this be the problem? Has anyone seen this before?
> >
> > I am using VC6.0 under Win NT and Win2K with no problems.
> > I don't think Win98 is to blame.
> >
>
> I didn't really mean Win98 was to blame, I'm pretty sure this is working
> fine. I'm more woried about the pthread stuff.
>
> > I don't think I use the pthread library, does that come with MSVC?
> > Have you tried compiling the example which works with pthread?
> >
>
> pthread is a library that gives windows users 'real' threads like those
> found on every other operating system, UNIX/LINUX, solaris and the like.
>
> I've tried some more stuff since mailing and found that if I load my models
> before I call glutMainLoop() they load fine. However, if I load model in a
> seperate thread it fails to load the textures.
>
> So, is PLIB thread safe?
>
> I've even tried running glutMainLoop in a seperate thread, and using the
> 'process' thread for loading models. This is also fails.
>
> >
> > >Kevin
> >
> > Bye bye,
> > Wolfram.
> >
>
> Cheers for the prompt responce,
>
> Kev
>
> >
> > -- __--__--
> >
>
> --__--__--
>
> Message: 2
> Date: Tue, 31 Oct 2000 02:49:29 -0600
> From: Steve Baker <sjb...@ai...>
> Organization: Steve at Home
> To: pli...@li...
> Subject: Re: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss)
> Reply-To: pli...@li...
>
> Kevin Glass wrote:
>
> > So, is PLIB thread safe?
>
> No.  And there isn't a whole lot of point in trying to make it
> that way when OpenGL isn't thread-safe.
>
> You can go some way towards using threads with PLIB but you really
> have to know what's going on and do things like pre-load all the
> textures using loader callbacks to assign them to the model parts
> rather than letting the loader do the work.

Ok, I didn't realise OpenGL wasn't thread-safe.

I thought that loading textures and creating display lists could be done without
interacting with anything being displayed? Is this something to do with the way glut works?

I could create a list of objects that need to be loaded in the thread. Then when the
glutIdle callback comes round I could the load the objects. Would this work? Can you see
any problems with this?

Cheers for any help,

Kev

PS. PLIB is really cool, 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
>
> --__--__--
>
> Message: 3
> From: "Paolo Leoncini" <p.l...@ci...>
> To: <pli...@li...>
> Subject: R: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss)
> Date: Tue, 31 Oct 2000 11:05:31 +0100
> charset="iso-8859-1"
> Reply-To: pli...@li...
>
> > > >I'm using VC6.0 on Win98. The code is threaded using the pthread
> > > >library, could this be the problem? Has anyone seen this before?
>
> As one can extrapolate from wgl function doc (e.g.
> http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/opengl/ntopn
> glr_6flf.htm for wglShareLists) OGL objects, as display lists and texture
> objects are, are not shared between processes.
> Well, are pthreads processes on Win9x? or are these just threads? Is there
> any difference? If pthread = process, then we have located the problem.
>

I believe that pthreads are real windows threads. Whether windows has anything really
thread like is another question. However, they don't show up as sepearte processes.

>
> >
> > pthread is a library that gives windows users 'real' threads like those
> > found on every other operating system, UNIX/LINUX, solaris and the like.
> >
> > I've tried some more stuff since mailing and found that if I load
> > my models
> > before I call glutMainLoop() they load fine. However, if I load model in a
> > seperate thread it fails to load the textures.
> >
> > So, is PLIB thread safe?
> >
>
> I don't think this is the actual problem. Rather it is the sharing of OGL
> object between processes.
>

I don't think it is actually sharing.

>
> > I've even tried running glutMainLoop in a seperate thread, and using the
> > 'process' thread for loading models. This is also fails.
> >
>
> Answered above.
>
> Greetings to all -
>
> ----------------------------------------------------------------------------
> -
> Paolo Leoncini                                          phone:  +39 (0823) 623134
> Scientific Visualization & Virtual Reality      fax:    +39 (0823) 623126
> CIRA - Italian Center for Aerospace Researches  mailto:p.l...@ci...
> Via Maiorise - 81043 Capua (CE) Italy           http://www.cira.it/research/vis
>
> > -----Messaggio originale-----
> > Da: pli...@li...
> > [mailto:pli...@li...]Per conto di Kevin Glass
> > Inviato: lunedì 30 ottobre 2000 22.16
> > A: pli...@li...
> > Oggetto: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss)
> >
> >
> >
> >
> > >
> > > Today's Topics:
> > >
> > >   1. Re: Loading AC Models and Textures (Wolfram Kuss)
> > >
> > > -- __--__--
> > >
> > > Message: 1
> > > From: Wolfram Kuss <w_...@rz...>
> > > To: pli...@li...
> > > Subject: Re: [Plib-users] Loading AC Models and Textures
> > > Date: Sun, 29 Oct 2000 20:12:54 +0000
> > > Organization: Hammes SW
> > > Reply-To: pli...@li...
> > >
> > > Kevin wrote:
> > >
> > > >Sometimes I get warnings when loading the models saying that the
> > > >textures can not be found. However, this does not happen consistantly.
> > > >When I do get these messages, the directories being used are not the
> > > >directory I set with model and texture path.
> > >
> > > Strange. Which directories do the error messages name and which do you
> > > use?
> >
> > The error messages (when they do show up) pertain to the current
> > directory,
> > or rather, where I run it from. Its as though the texture path is just
> > ignored.
> >
> > >
> > >
> > > >I'm using VC6.0 on Win98. The code is threaded using the pthread
> > > >library, could this be the problem? Has anyone seen this before?
> > >
> > > I am using VC6.0 under Win NT and Win2K with no problems.
> > > I don't think Win98 is to blame.
> > >
> >
> > I didn't really mean Win98 was to blame, I'm pretty sure this is working
> > fine. I'm more woried about the pthread stuff.
> >
> >
> > > I don't think I use the pthread library, does that come with MSVC?
> > > Have you tried compiling the example which works with pthread?
> > >
> >
> > pthread is a library that gives windows users 'real' threads like those
> > found on every other operating system, UNIX/LINUX, solaris and the like.
> >
> > I've tried some more stuff since mailing and found that if I load
> > my models
> > before I call glutMainLoop() they load fine. However, if I load model in a
> > seperate thread it fails to load the textures.
> >
> > So, is PLIB thread safe?
> >
> > I've even tried running glutMainLoop in a seperate thread, and using the
> > 'process' thread for loading models. This is also fails.
> >
> >
> >
> > >
> > > >Kevin
> > >
> > > Bye bye,
> > > Wolfram.
> > >
> >
> > Cheers for the prompt responce,
> >
> > Kev
> >
> > >
> > > -- __--__--
> > >
> >
> > _______________________________________________
> > plib-users mailing list
> > pli...@li...
> > http://lists.sourceforge.net/mailman/listinfo/plib-users
> >
>
> --__--__--
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>
> End of plib-users Digest_______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

R: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss)

[Paolo L. <p.l...@ci...>]

> > >I'm using VC6.0 on Win98. The code is threaded using the pthread
> > >library, could this be the problem? Has anyone seen this before?

As one can extrapolate from wgl function doc (e.g.
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/opengl/ntopn
glr_6flf.htm for wglShareLists) OGL objects, as display lists and texture
objects are, are not shared between processes.
Well, are pthreads processes on Win9x? or are these just threads? Is there
any difference? If pthread = process, then we have located the problem.

>
> pthread is a library that gives windows users 'real' threads like those
> found on every other operating system, UNIX/LINUX, solaris and the like.
>
> I've tried some more stuff since mailing and found that if I load
> my models
> before I call glutMainLoop() they load fine. However, if I load model in a
> seperate thread it fails to load the textures.
>
> So, is PLIB thread safe?
>

I don't think this is the actual problem. Rather it is the sharing of OGL
object between processes.

> I've even tried running glutMainLoop in a seperate thread, and using the
> 'process' thread for loading models. This is also fails.
>

Answered above.

Greetings to all -

----------------------------------------------------------------------------
-
Paolo Leoncini						phone:  +39 (0823) 623134
Scientific Visualization & Virtual Reality	fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches	mailto:p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		http://www.cira.it/research/vis

> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...]Per conto di Kevin Glass
> Inviato: lunedì 30 ottobre 2000 22.16
> A: pli...@li...
> Oggetto: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss)
>
>
>
>
> >
> > Today's Topics:
> >
> >   1. Re: Loading AC Models and Textures (Wolfram Kuss)
> >
> > --__--__--
> >
> > Message: 1
> > From: Wolfram Kuss <w_...@rz...>
> > To: pli...@li...
> > Subject: Re: [Plib-users] Loading AC Models and Textures
> > Date: Sun, 29 Oct 2000 20:12:54 +0000
> > Organization: Hammes SW
> > Reply-To: pli...@li...
> >
> > Kevin wrote:
> >
> > >Sometimes I get warnings when loading the models saying that the
> > >textures can not be found. However, this does not happen consistantly.
> > >When I do get these messages, the directories being used are not the
> > >directory I set with model and texture path.
> >
> > Strange. Which directories do the error messages name and which do you
> > use?
>
> The error messages (when they do show up) pertain to the current
> directory,
> or rather, where I run it from. Its as though the texture path is just
> ignored.
>
> >
> >
> > >I'm using VC6.0 on Win98. The code is threaded using the pthread
> > >library, could this be the problem? Has anyone seen this before?
> >
> > I am using VC6.0 under Win NT and Win2K with no problems.
> > I don't think Win98 is to blame.
> >
>
> I didn't really mean Win98 was to blame, I'm pretty sure this is working
> fine. I'm more woried about the pthread stuff.
>
>
> > I don't think I use the pthread library, does that come with MSVC?
> > Have you tried compiling the example which works with pthread?
> >
>
> pthread is a library that gives windows users 'real' threads like those
> found on every other operating system, UNIX/LINUX, solaris and the like.
>
> I've tried some more stuff since mailing and found that if I load
> my models
> before I call glutMainLoop() they load fine. However, if I load model in a
> seperate thread it fails to load the textures.
>
> So, is PLIB thread safe?
>
> I've even tried running glutMainLoop in a seperate thread, and using the
> 'process' thread for loading models. This is also fails.
>
>
>
> >
> > >Kevin
> >
> > Bye bye,
> > Wolfram.
> >
>
> Cheers for the prompt responce,
>
> Kev
>
> >
> > --__--__--
> >
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>

Re: [Plib-users] Re: Loading AC Models and Textures (Wolfram Kuss)

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

Kevin Glass wrote:

> So, is PLIB thread safe?

No.  And there isn't a whole lot of point in trying to make it
that way when OpenGL isn't thread-safe.

You can go some way towards using threads with PLIB but you really
have to know what's going on and do things like pre-load all the
textures using loader callbacks to assign them to the model parts
rather than letting the loader do the work.
 
-- 
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-users] Re: Loading AC Models and Textures (Wolfram Kuss)

[Kevin G. <av...@cu...>]

>
> Today's Topics:
>
>   1. Re: Loading AC Models and Textures (Wolfram Kuss)
>
> --__--__--
>
> Message: 1
> From: Wolfram Kuss <w_...@rz...>
> To: pli...@li...
> Subject: Re: [Plib-users] Loading AC Models and Textures
> Date: Sun, 29 Oct 2000 20:12:54 +0000
> Organization: Hammes SW
> Reply-To: pli...@li...
>
> Kevin wrote:
>
> >Sometimes I get warnings when loading the models saying that the
> >textures can not be found. However, this does not happen consistantly.
> >When I do get these messages, the directories being used are not the
> >directory I set with model and texture path.
>
> Strange. Which directories do the error messages name and which do you
> use?

The error messages (when they do show up) pertain to the current directory,
or rather, where I run it from. Its as though the texture path is just
ignored.

>
>
> >I'm using VC6.0 on Win98. The code is threaded using the pthread
> >library, could this be the problem? Has anyone seen this before?
>
> I am using VC6.0 under Win NT and Win2K with no problems.
> I don't think Win98 is to blame.
>

I didn't really mean Win98 was to blame, I'm pretty sure this is working
fine. I'm more woried about the pthread stuff.


> I don't think I use the pthread library, does that come with MSVC?
> Have you tried compiling the example which works with pthread?
>

pthread is a library that gives windows users 'real' threads like those
found on every other operating system, UNIX/LINUX, solaris and the like.

I've tried some more stuff since mailing and found that if I load my models
before I call glutMainLoop() they load fine. However, if I load model in a
seperate thread it fails to load the textures.

So, is PLIB thread safe?

I've even tried running glutMainLoop in a seperate thread, and using the
'process' thread for loading models. This is also fails.



>
> >Kevin
>
> Bye bye,
> Wolfram.
>

Cheers for the prompt responce,

Kev

>
> --__--__--
>

Re: [Plib-users] Loading AC Models and Textures

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

Kevin wrote:

>Sometimes I get warnings when loading the models saying that the
>textures can not be found. However, this does not happen consistantly.
>When I do get these messages, the directories being used are not the
>directory I set with model and texture path.

Strange. Which directories do the error messages name and which do you
use?


>I'm using VC6.0 on Win98. The code is threaded using the pthread
>library, could this be the problem? Has anyone seen this before?

I am using VC6.0 under Win NT and Win2K with no problems.
I don't think Win98 is to blame.
I don't think I use the pthread library, does that come with MSVC?
Have you tried compiling the example which works with pthread?

>Kevin

Bye bye,
Wolfram.

[Plib-users] Loading AC Models and Textures

[Kevin G. <av...@cu...>]

Hi,

I've recently started using PLIB 1.3. I've tried the demos and have had
the penguin on a pedastal. However, when I use this code in my own C++
objects I get the model appearing with no textures.

I've copied the same models, including the textures files into my local
models directory.

I've set the model and texture path to the appropriate place.

Sometimes I get warnings when loading the models saying that the
textures can not be found. However, this does not happen consistantly.
When I do get these messages, the directories being used are not the
directory I set with model and texture path.

I'm using VC6.0 on Win98. The code is threaded using the pthread
library, could this be the problem? Has anyone seen this before?

Thanks for any help,

Kevin

Re: [Plib-users] ATI Card and MESA

[<fa...@ya...>]

> 
> ...so is your's a "Rage 128", a "Rage Fury AGP", a
> "Rage Pro", a "Rage Fury Pro"
> or a "Rage 128 Pro" ??  What do they mean by
> "Minimal" support?  It's not all
> that clear!
> 
> I wish ATI would name each machine a little more
> clearly without using '128', 'Pro'
> and 'Fury' in random combinations!
> 
Thanks Steve, I didn't fully understand what DRI was,
but I can figure that out now. I can't understand why
ATI can't give their cards sensible names. My card can
have about three names. For example the chipset is
Rage 128, but then there is another card called Rage
128 as well. Strange...

Regards,

SiMON


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Re: [Plib-users] compiling plib on irix 6.2

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

Ian van der Neut wrote:

> >  * You could go back to PLIB 1.1.xx - it should compile just fine on your
> >    Indy since it didn't support Vertex Arrays.  You'll find all the old
> >    versions on the PLIB web site.
> 
> That's an option I guess depending on the amount of features I'd lose,
> but I don't know plib well enough yet to know.

There have certainly been quite a few features added (especially file
loaders) - but I guess 95% of it was there and working in 1.1.xx.  I
used that version to develop TuxKart.
 
> hmmm... I might be lucky, there's a whole bunch of those in gl.h
> #define GL_VERTEX_ARRAY_EXT                 0x8074
> #define GL_NORMAL_ARRAY_EXT                 0x8075
> #define GL_COLOR_ARRAY_EXT                  0x8076
> #define GL_TEXTURE_COORD_ARRAY_EXT          0x8078
> 
> hmm... maybe not so lucky :/
> 122(ian:)% grep glEnableClientState *
> gls.h:#define GLS_OP_glEnableClientState                286

You can probably just comment out that call.
 
> 122(ian:)% grep glVertexPointer *
> gl.h:extern void glVertexPointerEXT (GLint size, GLenum type, GLsizei
> stride, GLsizei count, const GLvoid *pointer);
> gls.h:#define GLS_OP_glVertexPointer                    292
> gls.h:#define GLS_OP_glVertexPointerEXT                 65501
> 
> The other ones it's failing on, are there too, with the GLS_OP prefix,
> but no function prototype :(

No the GLS prefix means something else - it's in gls.h - it's somewhat unrelated.
 
> OK, I'll just use the Linux box then.

Good plan.
 
> > Go get a *cheap* PC and install Linux.  Linux is *so* close to IRIX, you'll
> > hardly notice the difference.  I routinely switch between our big ONYX 2
> > machines at work and various Linux boxes - and while I'm working I *frequently*
> > forget which machine I'm logged into - they are *that* similar.
> 
> But they're a boring shade of grey, the Indy looks a lot sexier ;)

So splash out on an SGI PC - purple! (Lots of $$$ - Linux pre-installed!)

Go look in your local PC store - there are a gazillion $60 PC cases in our
local Fry's in a variety of cool colours and shapes.
 
> I know Linux very well, I've three Linux boxes here. Most of them are as
> old as the Indy though :) I'm not very fond of PC's, and yes, I'm very
> well aware that they are faster, but I just love the SGI, and I can't
> afford an Octane :/

Aside from it's shape/colour - I can't think of a single reason to stick with
an Indy (and I used to use one all the time at work).
 
> Thanks for your help Steve, would appreciate it if you could tell me
> what those defines are in gl.h and gls.h that I pasted, although I'm
> afraid it's not going to make that much of a difference. Can't hurt to
> know what they are.

GLS is a 'stream I/O' protocol for OpenGL - it allows you to pass OpenGL
calls down a comms link or save them into a file...stuff like that.

However, it doesn't do you much good to be able to shunt them around if
you can't render them when they get there!
 
-- 
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-users] Makefile ssgAux missing in 1.3.1

[Alexander R. <a_r...@in...>]

Hi,

I just installed plib-1.3.1 on my system, and I also got an error
because the Makefile for ssgAux is not created by configure.in

I'd rather like you developers to put plib-1.3.1.1 or so on your
homepage, it's annoying for anyone who gets it to do that himself -
although, on the other hand, it's an 'odd developer' version, so you
could say the people to download that should know to correct it
themselves.

What do you think?


Steve Wendt wrote:
> 
> On Wed, 18 Oct 2000 20:56:28 +0900, Kazuki Iizuka wrote:
> 
> >I have problem about plib-1.3.1.tar.gz  on Linux.
> >
> >       * Now, Makrfile is not created in only ssgAux-DIR.
> >       * Compiler says `no target' in ssgAux.
> 
> I think I had that problem too.  I just modified the scripts to add that dir...


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
     Project Homepage: http://tuxfleet.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-users] compiling plib on irix 6.2

[Ian v. d. N. <ian...@pr...>]

Steve Baker wrote:
> 
> Ian van der Neut wrote:
> 
> > Wanting to write a game for my kids, I wanted to try out plib, however
> > I'm running into problems compiling both plib 1.2.0 and 1.3.1 on my SGI
> > Indy running IRIX 6.2 and gcc/g++ (Yeah, I know it's old, and the game
> > won't really run on it, but I like developping on these boxes :).
> 
> Well - you won't get much speed out of it with textured polygons - but
> if you stick with plain or colour blended polygons, it should run passably
> well.

I know, the end result of the game will not run on the Indy, but on a
modern PC with a riva tnt2.
 
> 
> Er - GL_VERSION *always* has the value 0x1F02 in all versions of OpenGL
> because it's just a token that you pass to glGetString(GL_VERSION)
> when you are querying the version number at runtime.
> 
> However, you obviously have OpenGL 1.0 because version 1.1 and 1.2
> define tokens like GL_VERSION_1_1 and GL_VERSION_1_2.  There is no
> GL_VERSION_1_0. Anyway, this is an Indy and I know SGI didn't ever
> release an OpenGL 1.1 for machines that old.    :-)

I see.
 
> OK - we have been bad boys and wrote PLIB 1.2.0 to *require* OpenGL 1.1 or later.
> 
> There are some possible work-arounds:
> 
>  * We should probably put conditional compilation around the entire ssgVtxArray
>    class definition that make it be just an ssgVtxTable.  Vertex arrays didn't
>    exist in OpenGL 1.0.  However, since you may well be the last person on
>    the planet to still be running v1.0, my enthusiasm for a fix is minimal.

Don't bother, I'll just login to my gf's 600 MHz PIII Linux box with all
shiny hardware acceleration and software :)
 
>  * You could go back to PLIB 1.1.xx - it should compile just fine on your
>    Indy since it didn't support Vertex Arrays.  You'll find all the old
>    versions on the PLIB web site.

That's an option I guess depending on the amount of features I'd lose,
but I don't know plib well enough yet to know.
 
>  * You *might* get lucky and find that your machine had vertex arrays
>    implemented as OpenGL extensions.  Look for the missing functions
>    and tokens in /usr/include/GL/gl.h - they may be there with an 'EXT'
>    or 'SGI' tacked on the end...personally, I doubt you'll be that lucky,
>    but it's worth checking.

hmmm... I might be lucky, there's a whole bunch of those in gl.h
#define GL_VERTEX_ARRAY_EXT                 0x8074
#define GL_NORMAL_ARRAY_EXT                 0x8075
#define GL_COLOR_ARRAY_EXT                  0x8076
#define GL_TEXTURE_COORD_ARRAY_EXT          0x8078

hmm... maybe not so lucky :/
122(ian:)% grep glEnableClientState *
gls.h:#define GLS_OP_glEnableClientState                286

122(ian:)% grep glVertexPointer *
gl.h:extern void glVertexPointerEXT (GLint size, GLenum type, GLsizei
stride, GLsizei count, const GLvoid *pointer);
gls.h:#define GLS_OP_glVertexPointer                    292
gls.h:#define GLS_OP_glVertexPointerEXT                 65501

The other ones it's failing on, are there too, with the GLS_OP prefix,
but no function prototype :(

> > ssgVtxArray.cxx:77: `GL_COLOR_ARRAY' undeclared (first use this
> > ssgVtxArray.cxx:78: `GL_NORMAL_ARRAY' undeclared (first use this
> > ssgVtxArray.cxx:79: `GL_TEXTURE_COORD_ARRAY' undeclared (first use this
> > ssgVtxArray.cxx:80: `GL_VERTEX_ARRAY' undeclared (first use this
> > ssgVtxArray.cxx:80: warning: implicit declaration of function `int glEnableClientState(...)'
> > ssgVtxArray.cxx:82: warning: implicit declaration of function `int glVertexPointer(...)'
> > ssgVtxArray.cxx:89: warning: implicit declaration of function `int glDrawElements(...)'
> > ssgVtxArray.cxx:91: warning: implicit declaration of function `int glPopClientAttrib(...)'
> 
> All of these are the same thing basically.  OpenGL 1.0 doesn't implement
> vertex arrays and we need them.

OK, I'll just use the Linux box then.
 
> The software detected that you have an SGI machine - and tried to use the
> *NEW* IRIX sound library from IRIX 6.5 (or so).  Support for the new audio
> library is relatively new to PLIB - which is why you didn't see a problem
> with PLIB 1.2.0.
> 
> IRIX 6.2 used the old sound library - which is what we had in PLIB 1.2.0

I've been thinking about upgrading to 6.5, guess I will sometime in the
not too distant future. Anyway, doesn't matter if I'll just compile on
the Linux peecee.
 
> ...more of the same I'm afraid...these are all 'al' (Audio Library) functions.
> 
> I guess you are stuck with either dumping the PLIB sound code altogether - or
> sticking with the 'SL' from version 1.2.0 - which was the last version to support
> the old IRIX sound library.
> 
> > I have installed the latest libraries (CD image) that can be downloaded
> > from the SGI site. From swmgr, I can see that all GL development files
> > have been installed.
> 
> Yep.  That machine of yours is definitely showing it's age.  SGI don't
> actively support machines that old anymore - so you aren't going to find
> stuff like OpenGL 1.1/1.2 and the new sound library being ported to it.
> 
> Go get a *cheap* PC and install Linux.  Linux is *so* close to IRIX, you'll
> hardly notice the difference.  I routinely switch between our big ONYX 2
> machines at work and various Linux boxes - and while I'm working I *frequently*
> forget which machine I'm logged into - they are *that* similar.

But they're a boring shade of grey, the Indy looks a lot sexier ;)

I know Linux very well, I've three Linux boxes here. Most of them are as
old as the Indy though :) I'm not very fond of PC's, and yes, I'm very
well aware that they are faster, but I just love the SGI, and I can't
afford an Octane :/
 
> Bear in mind that a $128 GeForce-2 card in a $600 700MHz PC is considerably
> faster than a third of a million dollars worth of ONYX-2 Infinite Reality.
> Heck even a 266MHz PC with a Voodoo-1 card would wipe the floor with that
> Indy on both performance and image quality.

Sad, but true
 
> You'll probably also appreciate the way you can pick up 20Gb disk drives
> for $90 too - those old 1Gb Indy drives were pretty restrictive.

I've a 1 GB and a 3.2 GB in this baby, and one of the Linux boxes hosts
my home dir through NFS, so I have no lack of diskspace.
 
> I think it's time to wave goodbye to your old Indy buddy <sniff>.

NEVER! :)
 
> ...or pick up PLIB 1.1.xx if you *absolutely* must.
> ...or hack together a hybrid PLIB if you *really* have a lot of
>    time on your hands!

heh, with two kids running around? I don't think so :)
 
> *OR* (radical thought here) install Mesa on your Indy.  It'll run
> in software-only, so it'll be *REALLY* slow - but it will run PLIB 1.2.0
> and give you OpenGL 1.2.

nah, like I said, I'll just steal some CPU cycles and texture memory
from the gf's machine, she'll let me if I'm nice to her :)

Thanks for your help Steve, would appreciate it if you could tell me
what those defines are in gl.h and gls.h that I pasted, although I'm
afraid it's not going to make that much of a difference. Can't hurt to
know what they are.

Ian.
-- 
There's never enough time | To know is to know that
to do all the nothing you | you know nothing. That is
want.                     | the meaning of true knowledge.
-- Calvin                 | -- Confucius

Re: [Plib-users] compiling plib on irix 6.2

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

Ian van der Neut wrote:

> Wanting to write a game for my kids, I wanted to try out plib, however
> I'm running into problems compiling both plib 1.2.0 and 1.3.1 on my SGI
> Indy running IRIX 6.2 and gcc/g++ (Yeah, I know it's old, and the game
> won't really run on it, but I like developping on these boxes :).

Well - you won't get much speed out of it with textured polygons - but
if you stick with plain or colour blended polygons, it should run passably
well.

> I don't know if this is a FAQ, since I couldn't find no FAQ :)

Er - no - there aren't any questions that are asked frequently enough.

  :-)

> so sorry
> if it is a FAQ and I'll be happy with a direction to the FAQ, couldn't
> find anything similar in the mailing list archives either.

Don't sweat it - we're an easy going bunch here - we like to hear what
people are doing.
 
> version info:
> grep VERSION /usr/include/GL/gl.h
> #define GL_VERSION 0x1F02

Er - GL_VERSION *always* has the value 0x1F02 in all versions of OpenGL
because it's just a token that you pass to glGetString(GL_VERSION)
when you are querying the version number at runtime.

However, you obviously have OpenGL 1.0 because version 1.1 and 1.2
define tokens like GL_VERSION_1_1 and GL_VERSION_1_2.  There is no
GL_VERSION_1_0. Anyway, this is an Indy and I know SGI didn't ever
release an OpenGL 1.1 for machines that old.    :-)

> I'm getting the following errors when trying to build plib 1.2.0 ( I
> snipped the dirty X libs warnings ;):
> 
> gmake[2]: Entering directory `/usr/local/src/plib-1.2.0/src/ssg'
> c++ -DPACKAGE=\"plib\" -DVERSION=\"1.2.0\" -DHAVE_LIBDL=1 -DHAVE_LIBGL=1
> -DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DHAVE_LIBAUDIO=1 -DSTDC_HEADERS=1
> -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DGLUT_IS_PRESENT=1  -I. -I.
> -I../../src/sg -I../../src/util    -g -O2 -O6 -Wall -c ssgVtxArray.cxx
> In file included from /usr/include/GL/glx.h:21,
>                  from ssgLocal.h:13,
>                  from ssgVtxArray.cxx:2:
> 
> <dirty X lib warnings snipped>
> 
> ssgVtxArray.cxx: In method `void ssgVtxArray::drawHighlight(float *)':
> ssgVtxArray.cxx:75: `GL_CLIENT_VERTEX_ARRAY_BIT' undeclared (first use
> this function)

OK - we have been bad boys and wrote PLIB 1.2.0 to *require* OpenGL 1.1 or later.

There are some possible work-arounds:

 * We should probably put conditional compilation around the entire ssgVtxArray
   class definition that make it be just an ssgVtxTable.  Vertex arrays didn't
   exist in OpenGL 1.0.  However, since you may well be the last person on
   the planet to still be running v1.0, my enthusiasm for a fix is minimal.

 * You could go back to PLIB 1.1.xx - it should compile just fine on your
   Indy since it didn't support Vertex Arrays.  You'll find all the old
   versions on the PLIB web site.

 * You *might* get lucky and find that your machine had vertex arrays
   implemented as OpenGL extensions.  Look for the missing functions
   and tokens in /usr/include/GL/gl.h - they may be there with an 'EXT'
   or 'SGI' tacked on the end...personally, I doubt you'll be that lucky,
   but it's worth checking.

> ssgVtxArray.cxx:77: `GL_COLOR_ARRAY' undeclared (first use this
> ssgVtxArray.cxx:78: `GL_NORMAL_ARRAY' undeclared (first use this
> ssgVtxArray.cxx:79: `GL_TEXTURE_COORD_ARRAY' undeclared (first use this
> ssgVtxArray.cxx:80: `GL_VERTEX_ARRAY' undeclared (first use this
> ssgVtxArray.cxx:80: warning: implicit declaration of function `int glEnableClientState(...)'
> ssgVtxArray.cxx:82: warning: implicit declaration of function `int glVertexPointer(...)'
> ssgVtxArray.cxx:89: warning: implicit declaration of function `int glDrawElements(...)'
> ssgVtxArray.cxx:91: warning: implicit declaration of function `int glPopClientAttrib(...)'

All of these are the same thing basically.  OpenGL 1.0 doesn't implement
vertex arrays and we need them.

> When trying to build plib 1.3.1:

> slDSP.cxx:621: warning: implicit declaration of function `int alNewConfig(...)'

The software detected that you have an SGI machine - and tried to use the
*NEW* IRIX sound library from IRIX 6.5 (or so).  Support for the new audio
library is relatively new to PLIB - which is why you didn't see a problem
with PLIB 1.2.0.

IRIX 6.2 used the old sound library - which is what we had in PLIB 1.2.0

> slDSP.cxx:621: warning: assignment to `_ALconfig *'
> slDSP.cxx:623: warning: implicit declaration of function `int alSetChannels(...)'
> slDSP.cxx:624: warning: implicit declaration of function `int alSetWidth(...)'
> slDSP.cxx:625: warning: implicit declaration of function `int alSetQueueSize(...)'
> slDSP.cxx:627: warning: implicit declaration of function `int alOpenPort(...)'
> slDSP.cxx:627: warning: assignment to `_ALport *'
> slDSP.cxx:628: warning: implicit declaration of function `int alFreeConfig(...)'
> slDSP.cxx:637: `ALpv' undeclared (first use this function)

...more of the same I'm afraid...these are all 'al' (Audio Library) functions.

I guess you are stuck with either dumping the PLIB sound code altogether - or
sticking with the 'SL' from version 1.2.0 - which was the last version to support
the old IRIX sound library.

> I have installed the latest libraries (CD image) that can be downloaded
> from the SGI site. From swmgr, I can see that all GL development files
> have been installed.

Yep.  That machine of yours is definitely showing it's age.  SGI don't
actively support machines that old anymore - so you aren't going to find
stuff like OpenGL 1.1/1.2 and the new sound library being ported to it.

Go get a *cheap* PC and install Linux.  Linux is *so* close to IRIX, you'll
hardly notice the difference.  I routinely switch between our big ONYX 2
machines at work and various Linux boxes - and while I'm working I *frequently*
forget which machine I'm logged into - they are *that* similar.

Bear in mind that a $128 GeForce-2 card in a $600 700MHz PC is considerably
faster than a third of a million dollars worth of ONYX-2 Infinite Reality.

Heck even a 266MHz PC with a Voodoo-1 card would wipe the floor with that
Indy on both performance and image quality.

You'll probably also appreciate the way you can pick up 20Gb disk drives
for $90 too - those old 1Gb Indy drives were pretty restrictive.

I think it's time to wave goodbye to your old Indy buddy <sniff>.

...or pick up PLIB 1.1.xx if you *absolutely* must.
...or hack together a hybrid PLIB if you *really* have a lot of
   time on your hands!

*OR* (radical thought here) install Mesa on your Indy.  It'll run
in software-only, so it'll be *REALLY* slow - but it will run PLIB 1.2.0
and give you OpenGL 1.2.

-- 
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-users] compiling plib on irix 6.2

[Ian v. d. N. <ian...@pr...>]

Hi all,

Wanting to write a game for my kids, I wanted to try out plib, however
I'm running into problems compiling both plib 1.2.0 and 1.3.1 on my SGI
Indy running IRIX 6.2 and gcc/g++ (Yeah, I know it's old, and the game
won't really run on it, but I like developping on these boxes :).

I don't know if this is a FAQ, since I couldn't find no FAQ :) so sorry
if it is a FAQ and I'll be happy with a direction to the FAQ, couldn't
find anything similar in the mailing list archives either.

version info:
grep VERSION /usr/include/GL/gl.h
#define GL_VERSION 0x1F02


I'm getting the following errors when trying to build plib 1.2.0 ( I
snipped the dirty X libs warnings ;):

gmake[2]: Entering directory `/usr/local/src/plib-1.2.0/src/ssg'
c++ -DPACKAGE=\"plib\" -DVERSION=\"1.2.0\" -DHAVE_LIBDL=1 -DHAVE_LIBGL=1
-DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DHAVE_LIBAUDIO=1 -DSTDC_HEADERS=1
-DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DGLUT_IS_PRESENT=1  -I. -I. 
-I../../src/sg -I../../src/util    -g -O2 -O6 -Wall -c ssgVtxArray.cxx
In file included from /usr/include/GL/glx.h:21,
                 from ssgLocal.h:13,
                 from ssgVtxArray.cxx:2:

<dirty X lib warnings snipped>

ssgVtxArray.cxx: In method `void ssgVtxArray::drawHighlight(float *)':
ssgVtxArray.cxx:75: `GL_CLIENT_VERTEX_ARRAY_BIT' undeclared (first use
this function)
ssgVtxArray.cxx:75: (Each undeclared identifier is reported only once
ssgVtxArray.cxx:75: for each function it appears in.)
ssgVtxArray.cxx:75: warning: implicit declaration of function `int
glPushClientAttrib(...)'
ssgVtxArray.cxx:77: `GL_COLOR_ARRAY' undeclared (first use this
function)
ssgVtxArray.cxx:77: warning: implicit declaration of function `int
glDisableClientState(...)'
ssgVtxArray.cxx:78: `GL_NORMAL_ARRAY' undeclared (first use this
function)
ssgVtxArray.cxx:79: `GL_TEXTURE_COORD_ARRAY' undeclared (first use this
function)
ssgVtxArray.cxx:80: `GL_VERTEX_ARRAY' undeclared (first use this
function)
ssgVtxArray.cxx:80: warning: implicit declaration of function `int
glEnableClientState(...)'
ssgVtxArray.cxx:82: warning: implicit declaration of function `int
glVertexPointer(...)'
ssgVtxArray.cxx:89: warning: implicit declaration of function `int
glDrawElements(...)'
ssgVtxArray.cxx:91: warning: implicit declaration of function `int
glPopClientAttrib(...)'
ssgVtxArray.cxx: In method `void ssgVtxArray::drawHighlight(float *,
int)':
ssgVtxArray.cxx:118: confused by earlier errors, bailing out
gmake[2]: *** [ssgVtxArray.o] Error 1
gmake[2]: Leaving directory `/usr/local/src/plib-1.2.0/src/ssg'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/src/plib-1.2.0/src'
gmake: *** [all-recursive] Error 1


When trying to build plib 1.3.1:

Making all in sl
gmake[2]: Entering directory `/usr/local/src/plib-1.3.1/src/sl'
c++ -DPACKAGE=\"plib\" -DVERSION=\"1.3.1\" -DHAVE_LIBDL=1 -DHAVE_LIBGL=1
-DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DHAVE_LIBAUDIO=1 -DSTDC_HEADERS=1
-DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DGLUT_IS_PRESENT=1  -I. -I.   
-I/usr/local/include  -g -O2 -O6 -Wall -c slDSP.cxx
slDSP.cxx: In method `void slDSP::open(char *, int, int, int)':
slDSP.cxx:621: warning: implicit declaration of function `int
alNewConfig(...)'
slDSP.cxx:621: warning: assignment to `_ALconfig *' from `int' lacks a
cast
slDSP.cxx:623: warning: implicit declaration of function `int
alSetChannels(...)'
slDSP.cxx:624: warning: implicit declaration of function `int
alSetWidth(...)'
slDSP.cxx:625: warning: implicit declaration of function `int
alSetQueueSize(...)'
slDSP.cxx:627: warning: implicit declaration of function `int
alOpenPort(...)'
slDSP.cxx:627: warning: assignment to `_ALport *' from `int' lacks a
cast
slDSP.cxx:628: warning: implicit declaration of function `int
alFreeConfig(...)'
slDSP.cxx:637: `ALpv' undeclared (first use this function)
slDSP.cxx:637: (Each undeclared identifier is reported only once
slDSP.cxx:637: for each function it appears in.)
slDSP.cxx:637: parse error before `['
slDSP.cxx:639: `params' undeclared (first use this function)
slDSP.cxx:640: confused by earlier errors, bailing out
gmake[2]: *** [slDSP.o] Error 1
gmake[2]: Leaving directory `/usr/local/src/plib-1.3.1/src/sl'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/src/plib-1.3.1/src'
gmake: *** [all-recursive] Error 1

I have installed the latest libraries (CD image) that can be downloaded
from the SGI site. From swmgr, I can see that all GL development files
have been installed.

I'd appreciate any help, thanks,

Ian.
-- 
There's never enough time | To know is to know that
to do all the nothing you | you know nothing. That is
want.                     | the meaning of true knowledge.
-- Calvin                 | -- Confucius

Re: [Plib-users] ATI Card and MESA

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

Simon Foster wrote:
> 
> Sorry to ask a question not exactly about plib, but
> I've tried everywhere else and they can't help. How do
> I use my ATI Rage 128 (ATI Rage Fury Pro VIVO) card
> with Mesa, currently it will only do so s/w rendering
> which is too slow...

Well, I'm not clear whether it's supported or not -
http://www.mesa3d.org is the place to check - and a
swift 30 second reconnaisance mission turned up this
info:

1) You need to look at the Utah GLX project:

     http://utah-glx.sourceforge.net/

   Utah GLX support "Rage Pro" but NOT "Rage 128" - it's
   not clear from your post which you have since you mention
   both "128" and "Pro".

2) ...or the Precision Insight DRI project:

     http://dri.sourceforge.net

   Who claim to support:

     * ATI Rage 128 
       +  Rage Fury AGP 
       +    Rage Magnum AGP 
       +    XPERT 2000 AGP 
       +    XPERT 128 AGP 
       +    XPERT 99 AGP 
       +    All-in-Wonder 128 AGP 
       The PCI versions of these cards also have minimal
       support. Note that there are also Rage 128 Pro based
       boards on the market, and these are not yet
       supported. 

...so is your's a "Rage 128", a "Rage Fury AGP", a "Rage Pro", a "Rage Fury Pro"
or a "Rage 128 Pro" ??  What do they mean by "Minimal" support?  It's not all
that clear!

I wish ATI would name each machine a little more clearly without using '128', 'Pro'
and 'Fury' in random combinations!

-- 
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-users] ATI Card and MESA

[<fa...@ya...>]

Sorry to ask a question not exactly about plib, but
I've tried everywhere else and they can't help. How do
I use my ATI Rage 128 (ATI Rage Fury Pro VIVO) card
with Mesa, currently it will only do so s/w rendering
which is too slow... 

Regards,

SiMON

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/