plib-users

Re: [Plib-users] cygwin compile q's

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

Marlin Mixon wrote:

> 1. What is glx.h and where is it obtained?
> Also, is there a library that goes with it?

glx.h is an X-windows header file.  I don't think you should need it
with Cygwin.  It sounds like something isn't being configured correctly.
 
> 2. All of plib's .h files got put into /usr/include/plib.

Yes - that's the "official" place for the installed PLIB - all PLIB
applications are supposed to look there to find the headers.  Don't
even *THINK* of putting them anywhere else!

> I extended my
> PATH to include this directory...

Your include path should include "/usr/include" - and not /usr/include/plib,
this is because PLIB application programs say:

  #include <plib/{whatever}.h>

...which is analogous to the rules for OpenGL.  Where the headers
are supposed to be referred to by <GL/gl.h> - and the files are
in places like: /usr/include/GL/gl.h

-- 
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
                         http://freeglut.sourceforge.net

[Plib-users] cygwin compile q's

[Marlin M. <mar...@ho...>]

WARNING: The following posting contains raw newbie subject matter:

1. What is glx.h and where is it obtained?
Also, is there a library that goes with it?

2. All of plib's .h files got put into /usr/include/plib.  I extended my 
PATH to include this directory, but I still get gcc compile messages about 
missing .h files that are in /usr/include/plib.  I can diminish these 
messages one by one by stuffing the compile directory with symbolic links, 
but there's got to be a more elegant way...
Any ideas or am I just hallucinating?

Thanks,
Marlin


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [Plib-users] BGL Loader

[John T. <ndc...@mx...>]

Per Liedman wrote:

> John wrote:
> > Hi,
> >     I downloaded M$FS98 SDK (trying to figure out BGL
> format) and found a .hlp
> > file.
> >     Does anyone have experience on reading M$ .hlp
> files ?  (Without a Windo$
> > machine)
> >     I looked at wine's site, their experience told me
> winhlp32.exe doesn't work
> > yet at this point.
> >     I tried a decompiler (for win32 binary) by using
> wine, but that didn't work
> > either.
> >     By the way I found .asm files (asambly language files
> for Intel x86 cpu) in
> > the SDK package.
> >     Things are getting more and more interesting.
>
> I have a pdf-file with BGL documentation that is very good,
> but I have forgot where I got it from. I can send it to you
> when I get home.

Guess what, I found a hlp2rtflx converter.  It's a free binary for
linux.
http://www.herdsoft.com/ftp/downloads.html
I start reading the help file by StarOffice52.

This company is really cool. They also have a hlp2html CGI program so
that hlp files can start showing on the web BY Apache. They even claim
that they hope it won't be used to produce Windo$ applications.

Thanks

John Tsao

Re: [Plib-users] BGL Loader

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

John wrote:
> Hi,
>     I downloaded M$FS98 SDK (trying to figure out BGL 
format) and found a .hlp
> file.
>     Does anyone have experience on reading M$ .hlp 
files ?  (Without a Windo$
> machine)
>     I looked at wine's site, their experience told me 
winhlp32.exe doesn't work
> yet at this point.
>     I tried a decompiler (for win32 binary) by using 
wine, but that didn't work
> either.
>     By the way I found .asm files (asambly language files 
for Intel x86 cpu) in
> the SDK package.
>     Things are getting more and more interesting.

I have a pdf-file with BGL documentation that is very good, 
but I have forgot where I got it from. I can send it to you 
when I get home.

Regards,
Per

Re: [Plib-users] BGL Loader

[John T. <ndc...@mx...>]

Hi,
    I downloaded M$FS98 SDK (trying to figure out BGL format) and found a .hlp
file.
    Does anyone have experience on reading M$ .hlp files ?  (Without a Windo$
machine)
    I looked at wine's site, their experience told me winhlp32.exe doesn't work
yet at this point.
    I tried a decompiler (for win32 binary) by using wine, but that didn't work
either.
    By the way I found .asm files (asambly language files for Intel x86 cpu) in
the SDK package.
    Things are getting more and more interesting.

John Tsao

Re: [Plib-users] BGL Loader

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

John wrote:

>M$FS 3D scenery usually use .bgl files to present buildings.
>I am also a FGFS user. If we can have a BGL file loader in ppe, we can
>convert M$SFS secnery to objects that FG accepts.=20

Yes. Two or three people have asked about that already, but noone
seemed to be inclined to do the work. Like Per, I believe that
building on top of the MDL loader is best. I *think* the difference
between .MDL planes and scenery is fairly small, especially if you
only want to get the geometry in a first step and not all the
additional information like frequencies etc. If we have one module
that reads BGL commands, then maintaining it is easier.

You might also want to speak to Thomas Sevaldrud, the original author
of the MDL reading code.

>One problem I am not
>sure is that how thousands of BGL objects be rendered in FG. If I have a
>single (or not too many) MDL plane I can simply fly it.

IMHO there is an ascii file where you can input the position of static
objects in FGFS. Anyway, people, at least Rangathan (sp?) have done
it, so you should be able to get this info on the fgfs list.

>
>John Tsao

Bye bye,
Wolfram.

Re: [Plib-users] BGL Loader

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

On Monday 16 April 2001 04:10, Steve Baker wrote:
> John wrote:
> >     However they told me that only about a dozen out of 200 BGL commands
> > are involved in polygon drawing. I think this is expected because(?) BGL
> > files might contain more information about "positioning" those buildings
> > than the 3D models of those buildings.
>
> Yes - I can believe that.

If we just want the polys of the object, I think the MDL loader might already 
be fit for the task - it shouldn't be much more work than making the loader 
get the correct parts of the file. (The file structure is the only real 
difference between MDL/BGL AFAIK, both files contain BGL commands). All the 
documents should be on the internet - BGL is much better documented than MDL. 
Sadly enough, I don't have either the time or the motivation.

> > and figure out how to extract positioning information from BGLs'. Does
> > this sounds right?
>
> Well, I don't think you could use that positioning information because
> Curt's terrain and the MSFS terrain won't line up well enough.  You'd end
> up with lake-side buildings being roof-deep in water, bridges that are 100'
> away from the river they are supposed to cross - that kind of thing.

That's what it looks like in MSFS 2000 too :-) Flying down Grand Canyon 
proved to be *really* spectacular in MSFS 2000, since there were flying 
lakes, rivers and more...

Regards,
Per

-- 
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

Re: [Plib-users] BGL Loader

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

John wrote:

>     After talking to some MSFS developer, they told me there maybe already
> a scasm->dxf conveter (otherwise it's "dxf->scasm" converter instead of
> "scasm->dxf") and  possiblely in Window$ only. Too bad I don't have a
> Window$.

DXF is a pretty horrible format - it's designed for CAD systems and isn't
particularly friendly for the kinds of 3D you'd need for buildings and stuff.

>     However they told me that only about a dozen out of 200 BGL commands
> are involved in polygon drawing. I think this is expected because(?) BGL
> files might contain more information about "positioning" those buildings
> than the 3D models of those buildings.

Yes - I can believe that.

>     Anyway, I need to run the Window$ program without using Window$...

I guess you could try it under WINE on Linux.

> and figure out how to extract positioning information from BGLs'. Does this
> sounds right?

Well, I don't think you could use that positioning information because Curt's
terrain and the MSFS terrain won't line up well enough.  You'd end up with
lake-side buildings being roof-deep in water, bridges that are 100' away
from the river they are supposed to cross - that kind of thing.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] BGL Loader

[John <ndc...@mx...>]

I am new to this GPL world. Any one has an experience of asking some
help from a commercial company such as Fly! (Including changing their
marketing strategy)

I am just trying to help delevering a BGL loader.

John Tsao

Re: [Plib-users] BGL Loader

[John <ndc...@mx...>]

Steve Baker wrote:

> John wrote:
> >
> > Steve Baker wrote:
> >
> > > John wrote:
> > > >
> > > > Do we have any BGL loader project running now?
> > >
> > > What is BGL?  It's not a TLA that I'm familiar with...which
> > > means that there almost certainly isn't a BGL loader in the
> > > works right now.
> > >
> >
> > M$FS 3D scenery usually use .bgl files to present buildings.
>
> Ah - OK.
>
> > I am also a FGFS user. If we can have a BGL file loader in ppe, we
> > can convert M$SFS secnery to objects that FG accepts. One problem I
> > am not sure is that how thousands of BGL objects be rendered in FG.
>
> They would need to be referenced by the terrain files I would think.
>
> Generally, there are three kinds of features you need to think about:
>
>   1) Scattered objects - like trees, farmhouses, barns.
>      The models are generic and would be scattered randomly but
>      in 'typical' densities depending on what part of the world
>      you are in, the slope and nature of the terrain, etc.
>      (The scattering could either be in realtime - or performed
>      by the offline tools).
>
>   2) Generic features like bridges, radio towers and such that are
>      placed at very specific 'real world' locations by your tools.
>      You may also need to pick the right version of the library model
>      for the span of a bridge (to make it fit the width of the river
>      it's crossing) or the exact height of a radio tower.
>
>   3) Specifically modelled landmarks...things like the Eiffel Tower of
>      which there is uniquely only on on the planet and hence cannot
>      reasonably be pre-loaded into the simulator - but instead need to
>      be pulled in along with the terrain tile they belong to.
>
> Airport buildings tend to be type (2) or type (3).
>
> Anyway - the exact mechanism to implement this placement would be
> a question for Curt (who listens to this list).
>
> EIther way, having a PLIB BGL loader (and writer) would be an excellent
> starting point.

    After talking to some MSFS developer, they told me there maybe already
a scasm->dxf conveter (otherwise it's "dxf->scasm" converter instead of
"scasm->dxf") and  possiblely in Window$ only. Too bad I don't have a
Window$.
    However they told me that only about a dozen out of 200 BGL commands
are involved in polygon drawing. I think this is expected because(?) BGL
files might contain more information about "positioning" those buildings
than the 3D models of those buildings.
    Anyway, I need to run the Window$ program without using Window$, and
figure out how to extract positioning information from BGLs'. Does this
sounds right?

John Tsao

Re: [Plib-users] BGL Loader

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

John wrote:
> 
> Steve Baker wrote:
> 
> > John wrote:
> > >
> > > Do we have any BGL loader project running now?
> >
> > What is BGL?  It's not a TLA that I'm familiar with...which
> > means that there almost certainly isn't a BGL loader in the
> > works right now.
> >
> 
> M$FS 3D scenery usually use .bgl files to present buildings.

Ah - OK.

> I am also a FGFS user. If we can have a BGL file loader in ppe, we
> can convert M$SFS secnery to objects that FG accepts. One problem I
> am not sure is that how thousands of BGL objects be rendered in FG.

They would need to be referenced by the terrain files I would think.

Generally, there are three kinds of features you need to think about:

  1) Scattered objects - like trees, farmhouses, barns.
     The models are generic and would be scattered randomly but
     in 'typical' densities depending on what part of the world
     you are in, the slope and nature of the terrain, etc.
     (The scattering could either be in realtime - or performed
     by the offline tools).

  2) Generic features like bridges, radio towers and such that are
     placed at very specific 'real world' locations by your tools.
     You may also need to pick the right version of the library model
     for the span of a bridge (to make it fit the width of the river
     it's crossing) or the exact height of a radio tower.

  3) Specifically modelled landmarks...things like the Eiffel Tower of
     which there is uniquely only on on the planet and hence cannot
     reasonably be pre-loaded into the simulator - but instead need to
     be pulled in along with the terrain tile they belong to.

Airport buildings tend to be type (2) or type (3).

Anyway - the exact mechanism to implement this placement would be
a question for Curt (who listens to this list).

EIther way, having a PLIB BGL loader (and writer) would be an excellent
starting point.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] BGL Loader

[John <ndc...@mx...>]

Steve Baker wrote:

> John wrote:
> >
> > Do we have any BGL loader project running now?
>
> What is BGL?  It's not a TLA that I'm familiar with...which
> means that there almost certainly isn't a BGL loader in the
> works right now.
>

M$FS 3D scenery usually use .bgl files to present buildings.
I am also a FGFS user. If we can have a BGL file loader in ppe, we can
convert M$SFS secnery to objects that FG accepts. One problem I am not
sure is that how thousands of BGL objects be rendered in FG. If I have a
single (or not too many) MDL plane I can simply fly it.

John Tsao

Re: [Plib-users] BGL Loader

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

John wrote:
> 
> Do we have any BGL loader project running now?

What is BGL?  It's not a TLA that I'm familiar with...which
means that there almost certainly isn't a BGL loader in the
works right now.


-- 
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
                         http://freeglut.sourceforge.net

[Plib-users] BGL Loader

[John <ndc...@mx...>]

Do we have any BGL loader project running now?

John Tsao

Re: [Plib-users] The PUI example compile

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

Christian Mayer wrote:
> 
> Peter Gebauer wrote:
> >
> > Hey.
> >
> > Besides a few semantic errors in the code found on the project website
> > (PUI example) I'm having difficulties compiling it.
> > [...]
> > I'm sitting on a Linux (naturally) box and plib is compiled and ready for
> > use!
> 
> Hm, that sounds strange. The most recent change to any of the PUI
> examples is 4 months ago.
> 
> I guess that either your download broke in some way or your complier is
> faulty (Red Hat shiped one...)
> 
> So what OS and which compiler are you using? Did you check that the
> download didn't breake?

...And always, ALWAYS, *ALWAYS* include the precise error messages
that were emitted from the compiler when you email questions like this.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] The PUI example compile

[<Va...@t-...>]

Peter Gebauer wrote:
> 
> Hey.
> 
> Besides a few semantic errors in the code found on the project website
> (PUI example) I'm having difficulties compiling it.
> [...]
> I'm sitting on a Linux (naturally) box and plib is compiled and ready for
> use!

Hm, that sounds strange. The most recent change to any of the PUI
examples is 4 months ago.

I guess that either your download broke in some way or your complier is
faulty (Red Hat shiped one...)

So what OS and which compiler are you using? Did you check that the
download didn't breake?

CU,
Christian

[Plib-users] The PUI example compile

[Peter G. <pe...@re...>]

Hey.

Besides a few semantic errors in the code found on the project website
(PUI example) I'm having difficulties compiling it.
Even using the same flags as witht the example tarballs Makefiles fails to
compile it.
Can somebody show me the most simple way to compile a very simple PUI
example?
I'm sitting on a Linux (naturally) box and plib is compiled and ready for
use!

/Peter

Re: [Plib-users] Threading

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

"Curtis L. Olson" wrote:

> > Those things are tricky and not 100% guaranteed - but for what you describe,
> > there shouldn't be a problem.
> 
> We have just begun to explore the idea of updating the scene graph
> tree in a seperate thread from the main render thread.  Clearly you
> must never do anything in the update thread that could ever trigger an
> opengl command (such as loading/registering a texture for example.)
> 
> However, other than that we have been surprised that it has worked
> pretty well and is very robust.

Bear in mind that the PROBABILITY of a failure when you have a
threading error can be very small - so it's crucial that you *know*
that you are solidly "safe-by-design" because testing won't show up
the problem in any reasonable amount of time and debuggers are
largely useless.

Particularly:

  * Don't add or remove entries from ssgBranch nodes
    during ssgCullAndDraw or the LOS/HAT routines.

For scenery paging (which I'm guessing is what Curt is doing here),
you can build up a scenery tile in your parallel thread (being careful
about the texture load thing) - BUT connect that into the scene
graph when the tile is fully loaded - and do it in the rendering
thread - so you *know* that it's definitely not doing anything
while it's making the connection.

I generally build a pair of FIFO's between the rendering and paging
threads, passing the addresses of completed terrain tiles in one
direction and in the other direction, send the addresses of tiles
that have already been disconnected from the scene graph (by the
renderer) and which need to be physically deleted by the pager
to save time.

> Do know that threads are not necessarily nirvana, and unless you
> really know what you are doing and exactly what the threading will
> accomplish for you in advance, I'd recommend staying away from them as
> long as you can.

Yes. Without question.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] Threading

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

----- Original Message -----
From: "Curtis L. Olson" <cu...@me...>
To: <pli...@li...>
Sent: Wednesday, April 11, 2001 3:45 PM
Subject: Re: [Plib-users] Threading


> Do know that threads are not necessarily nirvana, and unless you
> really know what you are doing and exactly what the threading will
> accomplish for you in advance, I'd recommend staying away from them as
> long as you can.  You can do an amazing amount without them if you
> try.  If you do add threading, know that you are introducing a new
> layer of complexity in terms of software design, as well as in terms
> of debugging, and many assumptions your code may have made in the past
> might come around to bite you once you add threading ... and bite you
> in subtle hard to debug ways ... at inopportune times ...
>
> But heck, I'm not listening to my own advice so I suppose I shouldn't
> expect anyone else to ... :-)

Heh, yeah debugging threads can be a bit of a nightmare.  One thing I've
found that really helps is to make sure you are running on a multiprocessor
machine when you do all your debugging!  It really helps you stumble upon
race conditions and update conflicts that much earlier.  And what Curtis
says is correct - threads are not nirvana.  I've worked on a couple of
projects that (through naivety) started out multi-threaded, and then got all
the threads ripped out halfway through. :)

(When you're starting out it's very easy to make these mistakes - a server
application?  I'll have a new thread handle each client! doh! This stuff can
get complicated very quickly on server applications.  On an SMP box it makes
sense to have X number of threads each containing Y clients.  But tuning for
maximum efficiently is hard - what is the optimum number of threads for the
hardware your program finds it running on? 2, 4 or 8+ CPUs?  What's the
optimum number of clients per thread?  What about clients that are doing a
lot of data transfer Vs. those doing relatively little? And then you have to
start worring about making sure the access locks to your central datapool
are fine grained.  Whoops, getting a little OT here...)

My advice is - unless you are *absolutely* sure you need threads - stick
with single threaded apps.  If there are some areas where you believe
threading may help you then structure your design for a multi-threaded app
but code it single-threaded.  Get that version running and debugged and then
go multi-threaded.  BUT this does require careful design!

As an example, the "heap of concept work" that is SpaceThing
(www.spacething.org) is single threaded, but almost all the object access is
semaphore protected.  Currently in the release builds the locking functions
are replaced with inline "do nothing" functions.  In the debug builds a
couple of defines can switch it into multi-threaded mode - but there's all
sorts of problems with race-conditions and stuff that I keep encountering.
At the moment it doesn't seem worth the effort to hunt them down.

Sam

Disclaimer: Post written after a long haul coding session followed by curry
and a lot of beer.  I'll probably read this in the morning and think wft?!
:)

Re: [Plib-users] Threading

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

Steve Baker writes:
> Yes...if *all* the PLIB calls happen in that one thread - and all the OpenGL
> calls in that same thread - then there should be no problems.
> 
> What you can't do is things like playing with the scene graph in one thread
> and rendering it in the other because there is no internal protection against
> that kind of thing.
> 
> With extreme care, you could do things like building a new section of
> scene graph in one thread - and rendering a disconnected part of the
> scene graph in another - then when both processes finish working, connecting
> the new scene graph segment into the main tree.  Similarly, you could
> disconnect a section of the tree (when you know the rendering thread
> is idle) and delete it in the other thread.
> 
> Those things are tricky and not 100% guaranteed - but for what you describe,
> there shouldn't be a problem.

We have just begun to explore the idea of updating the scene graph
tree in a seperate thread from the main render thread.  Clearly you
must never do anything in the update thread that could ever trigger an
opengl command (such as loading/registering a texture for example.)

However, other than that we have been surprised that it has worked
pretty well and is very robust.

Do know that threads are not necessarily nirvana, and unless you
really know what you are doing and exactly what the threading will
accomplish for you in advance, I'd recommend staying away from them as
long as you can.  You can do an amazing amount without them if you
try.  If you do add threading, know that you are introducing a new
layer of complexity in terms of software design, as well as in terms
of debugging, and many assumptions your code may have made in the past
might come around to bite you once you add threading ... and bite you
in subtle hard to debug ways ... at inopportune times ...

But heck, I'm not listening to my own advice so I suppose I shouldn't
expect anyone else to ... :-)

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-users] Threading

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

Treasa Parakkat wrote:

> Can PLIB run in a separate thread? I mean, can my main program spawn off a
> thread that does all my PLIB calls without any problems?

Yes...if *all* the PLIB calls happen in that one thread - and all the OpenGL
calls in that same thread - then there should be no problems.

What you can't do is things like playing with the scene graph in one thread
and rendering it in the other because there is no internal protection against
that kind of thing.

With extreme care, you could do things like building a new section of
scene graph in one thread - and rendering a disconnected part of the
scene graph in another - then when both processes finish working, connecting
the new scene graph segment into the main tree.  Similarly, you could
disconnect a section of the tree (when you know the rendering thread
is idle) and delete it in the other thread.

Those things are tricky and not 100% guaranteed - but for what you describe,
there shouldn't be a problem.

> Also, when running PLIB, does it spawn any threads or create any new
> processes?

No...although the underlying OpenGL implementation might.


-- 
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
                         http://freeglut.sourceforge.net

[Plib-users] Threading

[Treasa P. <tpa...@gs...>]

I am considering using PLIB, but have a couple questions concerning its
"thread-ability".

Can PLIB run in a separate thread? I mean, can my main program spawn off a
thread that does all my PLIB calls without any problems?

Also, when running PLIB, does it spawn any threads or create any new
processes?

Thanks in advance,
Treasa Parakkat

Re: [Plib-users] PLib compilation fails on OpenBSD

[Heikki K. <he...@sa...>]

On Sun, 8 Apr 2001, Steve Baker wrote:

> So that redirects *all* of your ioctls via some OSS emulator?  Even the ones
> that are nothing to do with sound?  Yuk!  What a *horrible* kludge!

If soundcard.h is included, I assume so. (Anyone?)

> > /usr/include/sys/ioctl.h:int    ioctl __P((int, unsigned long, ...));
> > soundcard.h gives you Linux OSS emulation.
> Hmmmm - sortof - certainly it failed to do so in this case.

I don't remember SDL having this problem. (It had problems with MMX
instead. :-)

> I wonder why only *Open* BSD suffers from this problem?  I thought all the BSD varients
> were pretty similar these days?  (I guess that's typical of a Linux user's perspective!)

There are similarities.

Although, NetBSD, I would imagine, might suffer from this thing with OSS
too. It will not complain because plib uses the native API. My SSH client
is having some problems, so I can't check this out from CVS right now.

<!-- ---------------------- 72 characters -------------------------- -->
                   Heikki Korpela -- he...@sa...

Re: [Plib-users] PLib compilation fails on OpenBSD

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

Heikki Korpela wrote:
> 
> > On Sun, 8 Apr 2001, I wrote on a plib (http://plib.sourceforge.net)
> > compilation problem:
> > > sl.h:96: macro `ioctl' used with only 2 args
> 
> On Sun, 8 Apr 2001, Steve Baker wrote:
> 
> > I think (from the sound of the error), that OpenBSD has somehow defined 'ioctl'
> > as a macro - that's **WRONG** because in C++ you should be able to overload
> > the names of system functions (as we have done here) - but if the host OS
> > defines them as macro's, that won't work.
> 
> /usr/include/soundcard.h:#define ioctl(fd, com, argp) _oss_ioctl(fd, com, argp)

Eeeuuuwwww!  That **STINKS**.

So that redirects *all* of your ioctls via some OSS emulator?  Even the ones
that are nothing to do with sound?  Yuk!  What a *horrible* kludge!

So if I say:

  int (*func)(...) ;
  func = ioctl ;
  (*func)(...) ;

...it all falls apart!

> /usr/include/sys/ioctl.h:int    ioctl __P((int, unsigned long, ...));
> 
> soundcard.h gives you Linux OSS emulation.

Hmmmm - sortof - certainly it failed to do so in this case.
 
> Preferred way on OpenBSD is to use sys/audioio.h, which is the native
> audio interface and generally best kept up-to-date.
> 
> slPortability.h tries to use OSS instead, however.

Well, OSS has a richer interface than /dev/audio - and it's a lot more
widely supported across platforms...I'd prefer to use OSS if possible.
 
> A simple workaround as follows. I guess you would have to have a
> way to use OSS too under OpenBSD, though.
> 
> diff -uNr plib-1.2.0.orig/src/sl/slPortability.h plib-1.2.0/src/sl/slPortability.h
> --- plib-1.2.0.orig/src/sl/slPortability.h      Wed Jun 28 04:32:58 2000
> +++ plib-1.2.0/src/sl/slPortability.h   Mon Apr  9 06:50:37 2001
> @@ -42,7 +42,7 @@
>  #include <limits.h>
>  #include <math.h>
> 
> -#if (defined(__linux__) || defined(BSD)) && !defined(__NetBSD__)
> +#if (defined(__linux__) || defined(BSD)) && !defined(__NetBSD__) && !defined(__OpenBSD__)
>  #define SL_USING_OSS_AUDIO 1
>  #endif

I wonder why only *Open* BSD suffers from this problem?  I thought all the BSD varients
were pretty similar these days?  (I guess that's typical of a Linux user's perspective!)

Well, I think it might be better just to rename our ioctl member function and stick with
OSS.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] PLib compilation fails on OpenBSD

[Heikki K. <he...@sa...>]

> On Sun, 8 Apr 2001, I wrote on a plib (http://plib.sourceforge.net)
> compilation problem:
> > sl.h:96: macro `ioctl' used with only 2 args

On Sun, 8 Apr 2001, Steve Baker wrote:

> I think (from the sound of the error), that OpenBSD has somehow defined 'ioctl'
> as a macro - that's **WRONG** because in C++ you should be able to overload
> the names of system functions (as we have done here) - but if the host OS
> defines them as macro's, that won't work.

/usr/include/soundcard.h:#define ioctl(fd, com, argp) _oss_ioctl(fd, com, argp)
/usr/include/sys/ioctl.h:int    ioctl __P((int, unsigned long, ...));

soundcard.h gives you Linux OSS emulation.

Preferred way on OpenBSD is to use sys/audioio.h, which is the native
audio interface and generally best kept up-to-date.

slPortability.h tries to use OSS instead, however.

A simple workaround as follows. I guess you would have to have a
way to use OSS too under OpenBSD, though.

diff -uNr plib-1.2.0.orig/src/sl/slPortability.h plib-1.2.0/src/sl/slPortability.h
--- plib-1.2.0.orig/src/sl/slPortability.h      Wed Jun 28 04:32:58 2000
+++ plib-1.2.0/src/sl/slPortability.h   Mon Apr  9 06:50:37 2001
@@ -42,7 +42,7 @@
 #include <limits.h>
 #include <math.h>

-#if (defined(__linux__) || defined(BSD)) && !defined(__NetBSD__)
+#if (defined(__linux__) || defined(BSD)) && !defined(__NetBSD__) && !defined(__OpenBSD__)
 #define SL_USING_OSS_AUDIO 1
 #endif

With CFLAGS set to include and link with /usr/local and /usr/X11R6/lib,
this should build under OpenBSD 2.8-current. Haven't yet tried
actually running anything with it, tho.

I guess I should update my XF to OpenBSD snapshot of XF4 and try
and compile plib against it while I'm at it.

<!-- ---------------------- 72 characters -------------------------- -->
                   Heikki Korpela -- he...@sa...