plib-devel

RE: [Plib-devel] Update TODO list again!

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

I thought it would be best to keep it in there for a few days, gives people
a chance to say, hey that was not complete or the bug is still there. In
case I made a mistake. But if you want I will remove it.
 
Later Ben

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Thursday, August 31, 2000 2:37 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] Update TODO list again!



Ben wrote: 
> Alright here is the next version on the todo list. 

I don't see the need to include 'COMPLETED TASKS' in the TODO list.  That
belongs in the CHANGES file 

-- Dave McClurg 
mailto:dp...@ef... <mailto:dp...@ef...>  
http://mcdave.cjb.net <http://mcdave.cjb.net>  

RE: [Plib-devel] Update TODO list again!

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

Ben wrote:
> Alright here is the next version on the todo list. 

I don't see the need to include 'COMPLETED TASKS' in the TODO list.  That
belongs in the CHANGES file

-- Dave McClurg
mailto:dp...@ef...
http://mcdave.cjb.net

RE: [Plib-devel] Cleaner TODO list with updates.

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

Hi John,

> John Fay <fa...@tc...> contributed some 
> patches to PUI to make it work better with multiple 
> windows.  Sorry John - I didn't get time to try them. 
> Check the archives for the message entitled: 
>
>        [Plib-devel] PUI 1.3.0 in Multiple Windows 
>        Mon, 17 Jul 2000 15:31:41 -0500 

If you go ahead with this, could you do it conditionally?

#define _PU_USE_GLUT_WINDOWS   1
#ifdef _PU_USE_GLUT_WINDOWS
#endif

pu.h already has "_PU_USE_GLUT_FONTS" if you want use that as an example.
This will allow non-glut users to still use PUI and less headache for me
when I port to embedded systems.

Thanks,

-- Dave McClurg
mailto:dp...@ef...
http://mcdave.cjb.net

RE: [Plib-devel] Cleaner TODO list with updates.

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

This is the tobe done list for plib, if you would like to add any=20
additional information to this list please e-mail me at=20
tj...@is... (Ben Woodhead).=20

WAITING APPROVAL


FEATURES

SSG doesn't manage texture environment modes
(GL_MODULATE, GL_DECAL etc.)=20
But texture environments are global not per texture!

Owner:
Importance:

Sort leaf nodes by material property.

Owner
Importance: Much Overdue (Steves comment)


Enhance ssgState to allow for some of the more common/useful extensions =

to OpenGL.=20

Owner:=0D
Importance:

Curt Olson has a nifty 'sky' model class in 'SimGear' that is really=20
just *begging* to go into an SSG Utilities library.

       http://www.simgear.org/Docs/SGSky/=20

Check out the email thread 'SGSky class'=20

Owner:=20
Importance: High

Dave Lawrence posted a 'frame rate limiter' routine=20
that may be usefully added as a feature to ulClock.=20

Owner:
Importance:=20

Timing  (ssgTimedSelector in) *realtime* and frame-time.=20

Owner: Dave
Importance:

Blender-VRML loader developement should be continued.

Owner:
Importance:

Leath Muller sent me 'lwload.cxx' and 'lwload.h' files which he says =
would make=20
a good starting point for a 'LightWave' loader.  It would be nice to =
investigate=20
that.=20

Owner:
Importance:

Multiple textures per polygon.=20

Owner:
Importance:

BUGS

If the user calls "setValuator" with a pointer-to-float
argument and then calls it again with a pointer-to-integer
argument you will get some strange results. =20
Specifically, his integer variable will be overwritten with
the integer equivalent of his floating-point variable, both
immediately and whenever "getValue" is called.

Owner:
Importance:

FlightGear discovered that if you set *insane* values for=20
pitch (207.44) and volume (30.1289) on their engine sound,=20
SL would *crash*.  Obviously those are silly values - but=20
SL shouldn't crash because of it.  That also came from Curt.=20

Owner:
Importance:

Dave said that he thinks the bug in _ssgShareState seems to have
 'gone away' - and found that he could put it back into the code=20
without breaking TuxAQFH.=20

     It needs to be tested - and someone needs to look through the=20
     email archives to find out why it was originally commented out.=20

Owner:=20
Importance:

3ds loading issue, must find thread regarding this.

Owner:
Importance

PATCHES

Darrell Walisser contributed a number of MacOS patches.=20
Sorry Darrell - I didn't have time to commit these. Look for the email =
thread:=20

        [Plib-devel] Mac Updates/Patches (Tux too!)=20
        Thu, 03 Aug 2000 16:20:49 EST=20

Owner:
Importance:

John Fay <fa...@tc...> contributed some=20
patches to PUI to make it work better with multiple=20
windows.  Sorry John - I didn't get time to try them.=20
Check the archives for the message entitled:=20

       [Plib-devel] PUI 1.3.0 in Multiple Windows=20
       Mon, 17 Jul 2000 15:31:41 -0500=20

Owner:
Importance:

OPTIMIZATION


CODE CLEAN AND PORTABLITY

Clean up ulNet code to be portable with Mac's as well as additional =
testing
and code cleaning

Owner: Ben
Importance: Low

We really need to stop and think about "Loader Service Routines" before
we go too much further down the loader writing curve.
I'd expect nearly any loader to benefit from:
=20
* Polygon decimation to triangles.
* Optimal Tristrip creation.
* Parser support.
* Callbacks for applications that need to extend the
    file format via comment fields, etc.
* Callbacks for applications that need to build their
    own ssgStates.
* Surface normal generation.
* Degenerate triangle/vertex removal.
* Flattening (multiplying out the matrices in ssgTransform
    nodes and doing a one-time transform of vertices in the
    leaf node)
* Degenerate group removal (eg deleting ssgBranch nodes with
    either one or zero children - but only if the node isn't
    known to the application - or a derived class of ssgBranch).
* ssgState sharing between leaf nodes.
* Texture coordinate size reduction.
...and probably a lot more.

Owner: Dave
Importance: High
=20

MISC

Documentation - this is especially problematic for SSG which has =
undergone=20
a TON of changes since 1.0.5-ish (which is the last time I did a =
serious=20
sync-up between the code and the manual).  The other libraries aren't=20
too far out of date - but they could probably be read against the =
header=20
files to be sure that every public function is explained for every =
class.=20
(as a minimum).=20

Owner:
Importance: Very high

COMPLETED TASKS

Sam Stickland posted a patch to allow PUI menu's to be resized.  I =
havn't=20
had time to deal with that (sorry Sam)...but since he now has CVS =
access, I=20
guess he can do it himself now.=20

Owner: Sam
Importance:

The new ssgVtxArray class could be made more efficient (especially for =
GeForce=20
cards) if we added the option to pass Normal arrays as 'short' or =
'byte' and=20
Colour arrays as 'byte'.  At present, we have both of those as 'float' =
- so=20
to send a vertex to T&L hardware like GeForce or Radion is taking ~48 =
bytes.=20
If we could cut the precision, we'd only send ~27 bytes.  Since data =
transfer=20
to the card is very often the limiting factor with hardware T&L, we =
could perhaps=20
double performance on those cards without harming non-T&L cards.  The =
loss in=20
precision doesn't matter because normals are pretty much only used for =
lighting -=20
which in the end produces an 8 bit result - and colours are hardly =
every more=20
than 8 bits - even with 32 bits per pixel frame buffer depth.=20

Owner:
Importance:

There have been some comments about the need to delete PUI nodes during =

their own callback functions.  Read the thread:=20

      [Plib-devel] listbox and filepicker=20
      Fri, 4 Aug 2000 10:51:38 -0700=20

Owner: Dave
Importance:

Dave has been worrying about ssgSelector nodes with more than 32 =
children.
This really does need to be done soon because it's holding up some of =
the=20
loader work.  What's tricky (with the >32 kids problem) is keeping it=20
backwards compatible.  Notice especially the need to have MULTIPLE =
children=20
selectable at one - which is needed for some derived classes.=20

Owner: Dave
Importance:  High

[Plib-devel] Update TODO list again!

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

This is the tobe done list for plib, if you would like to add any=20
additional information to this list please e-mail me at=20
tj...@is... (Ben Woodhead).=20

WAITING APPROVAL


FEATURES

SSG doesn't manage texture environment modes
(GL_MODULATE, GL_DECAL etc.)=20
But texture environments are global not per texture!

Owner:
Importance:

Sort leaf nodes by material property.

Owner
Importance: Much Overdue (Steves comment)


Enhance ssgState to allow for some of the more common/useful extensions =

to OpenGL.=20

Owner:=0D
Importance:

Curt Olson has a nifty 'sky' model class in 'SimGear' that is really=20
just *begging* to go into an SSG Utilities library.

       http://www.simgear.org/Docs/SGSky/=20

Check out the email thread 'SGSky class'=20

Owner:=20
Importance: High

Dave Lawrence posted a 'frame rate limiter' routine=20
that may be usefully added as a feature to ulClock.=20

Owner:
Importance:=20

Timing  (ssgTimedSelector in) *realtime* and frame-time.=20

Owner: Dave
Importance:

Dave has been worrying about ssgSelector nodes with more than 32 =
children.
This really does need to be done soon because it's holding up some of =
the=20
loader work.  What's tricky (with the >32 kids problem) is keeping it=20
backwards compatible.  Notice especially the need to have MULTIPLE =
children=20
selectable at one - which is needed for some derived classes.=20

Owner: Dave
Importance:  High

Blender-VRML loader developement should be continued.

Owner:
Importance:

Leath Muller sent me 'lwload.cxx' and 'lwload.h' files which he says =
would make=20
a good starting point for a 'LightWave' loader.  It would be nice to =
investigate=20
that.=20

Owner:
Importance:

Multiple textures per polygon.=20

Owner:
Importance:

BUGS

If the user calls "setValuator" with a pointer-to-float
argument and then calls it again with a pointer-to-integer
argument you will get some strange results. =20
Specifically, his integer variable will be overwritten with
the integer equivalent of his floating-point variable, both
immediately and whenever "getValue" is called.

Owner:
Importance:

FlightGear discovered that if you set *insane* values for=20
pitch (207.44) and volume (30.1289) on their engine sound,=20
SL would *crash*.  Obviously those are silly values - but=20
SL shouldn't crash because of it.  That also came from Curt.=20

Owner:
Importance:

Dave said that he thinks the bug in _ssgShareState seems to have
 'gone away' - and found that he could put it back into the code=20
without breaking TuxAQFH.=20

     It needs to be tested - and someone needs to look through the=20
     email archives to find out why it was originally commented out.=20

Owner:=20
Importance:

3ds loading issue, must find thread regarding this.

Owner:
Importance

PATCHES

Darrell Walisser contributed a number of MacOS patches.=20
Sorry Darrell - I didn't have time to commit these. Look for the email =
thread:=20

        [Plib-devel] Mac Updates/Patches (Tux too!)=20
        Thu, 03 Aug 2000 16:20:49 EST=20

Owner:
Importance:

John Fay <fa...@tc...> contributed some=20
patches to PUI to make it work better with multiple=20
windows.  Sorry John - I didn't get time to try them.=20
Check the archives for the message entitled:=20

       [Plib-devel] PUI 1.3.0 in Multiple Windows=20
       Mon, 17 Jul 2000 15:31:41 -0500=20

Owner:
Importance:

OPTIMIZATION


CODE CLEAN AND PORTABLITY

Clean up ulNet code to be portable with Mac's as well as additional =
testing
and code cleaning

Owner: Ben
Importance: Low

We really need to stop and think about "Loader Service Routines" before
we go too much further down the loader writing curve.
I'd expect nearly any loader to benefit from:
=20
* Polygon decimation to triangles.
* Optimal Tristrip creation.
* Parser support.
* Callbacks for applications that need to extend the
    file format via comment fields, etc.
* Callbacks for applications that need to build their
    own ssgStates.
* Surface normal generation.
* Degenerate triangle/vertex removal.
* Flattening (multiplying out the matrices in ssgTransform
    nodes and doing a one-time transform of vertices in the
    leaf node)
* Degenerate group removal (eg deleting ssgBranch nodes with
    either one or zero children - but only if the node isn't
    known to the application - or a derived class of ssgBranch).
* ssgState sharing between leaf nodes.
* Texture coordinate size reduction.
...and probably a lot more.

Owner:
Importance: High
=20

MISC

Documentation - this is especially problematic for SSG which has =
undergone=20
a TON of changes since 1.0.5-ish (which is the last time I did a =
serious=20
sync-up between the code and the manual).  The other libraries aren't=20
too far out of date - but they could probably be read against the =
header=20
files to be sure that every public function is explained for every =
class.=20
(as a minimum).=20

Owner:
Importance: Very high

COMPLETED TASKS

Sam Stickland posted a patch to allow PUI menu's to be resized.  I =
havn't=20
had time to deal with that (sorry Sam)...but since he now has CVS =
access, I=20
guess he can do it himself now.=20

Owner: Sam
Importance:

The new ssgVtxArray class could be made more efficient (especially for =
GeForce=20
cards) if we added the option to pass Normal arrays as 'short' or =
'byte' and=20
Colour arrays as 'byte'.  At present, we have both of those as 'float' =
- so=20
to send a vertex to T&L hardware like GeForce or Radion is taking ~48 =
bytes.=20
If we could cut the precision, we'd only send ~27 bytes.  Since data =
transfer=20
to the card is very often the limiting factor with hardware T&L, we =
could perhaps=20
double performance on those cards without harming non-T&L cards.  The =
loss in=20
precision doesn't matter because normals are pretty much only used for =
lighting -=20
which in the end produces an 8 bit result - and colours are hardly =
every more=20
than 8 bits - even with 32 bits per pixel frame buffer depth.=20

Owner:
Importance:

There have been some comments about the need to delete PUI nodes during =

their own callback functions.  Read the thread:=20

      [Plib-devel] listbox and filepicker=20
      Fri, 4 Aug 2000 10:51:38 -0700=20

Owner: Dave
Importance:

RE: [Plib-devel] Cleaner TODO list with updates.

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

Hi Ben,

I'd like to take ownership of the one about "Loader Service Routines".

Also, these items are already done:

> There have been some comments about the need to delete PUI nodes during 
> their own callback functions.  Read the thread: 
>
>      [Plib-devel] listbox and filepicker 
>      Fri, 4 Aug 2000 10:51:38 -0700 
http://www.geocrawler.com/archives/3/1868/2000/8/0/4183906/

> Dave has been worrying about ssgSelector nodes with more than 32 children.
> This really does need to be done soon because it's holding up some of the 
> loader work.  What's tricky (with the >32 kids problem) is keeping it 
> backwards compatible.  Notice especially the need to have MULTIPLE
children 
> selectable at one - which is needed for some derived classes. 
> 
http://www.geocrawler.com/archives/3/1868/2000/8/0/4139079/


-- Dave McClurg
mailto:dp...@ef...
http://mcdave.cjb.net

RE: [Plib-devel] Update TODO list

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

Hi John,
I think you missed this message (08/12/2000 23:13:07).
Here is a copy in the archives:

http://www.geocrawler.com/archives/3/1868/2000/8/0/4183906/

This change is already in CVS.  The source looks like this:

  if ( ob -> getType () & PUCLASS_INTERFACE )
    puPopLiveInterface ( (puInterface*)ob ) ;

Notice the '&'.

--Dave

> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...]On Behalf Of Fay John F
> Contr AAC/WMG
> Sent: Thursday, August 31, 2000 9:18 AM
> To: pli...@li...
> Subject: RE: [Plib-devel] Update TODO list
> 
> 
> <begin quote>
> Sorry about the delay in responding to this; I missed it the 
> first time it
> came around and just found it in the TODO list.
>  
> I think the problem in deleting the wrong dialog box comes from the
> "puPopLiveInterface ()" call in the "puInterface" destructor.  I would
> tentatively fix it by removing the call from the destructor 
> and placing it
> in the "puDeleteObject" function:
>  
> if ( ob->getType() | PUCLASS_INTERFACE )
>   puPopLiveInterface () ;
>  
> I don't have any applications where dialog boxes create other 
> dialog boxes
> while destroying themselves so I can't test it out, but a 
> look at the code
> makes me think it will work.  Can someone check it out for me 
> please?  I put
> it into my own application and it doesn't seem to have broken 
> anything.  
>  
> <end quote>
> 
> John F. Fay
> joh...@eg...
> 
> 
> -----Original Message-----
> From: Ben Woodhead [mailto:be...@bg...]
> Sent: Thursday, August 31, 2000 08:24
> To: 'pli...@li...'
> Subject: RE: [Plib-devel] Update TODO list
> 
> 
> Sorry, I don't have your original suggestion, I will create a 
> section for
> waiting for approval if you want to send me your original 
> suggestion again.
> 
> Thanks Ben
> 
> > -----Original Message-----
> > From: Fay John F Contr AAC/WMG [mailto:joh...@eg...]
> > Sent: Thursday, August 31, 2000 10:21 AM
> > To: pli...@li...
> > Subject: RE: [Plib-devel] Update TODO list
> > 
> > 
> > I put a suggested fix for the "puDeleteObject" onto the list 
> > but I don't
> > know whether anybody ran with it.  I also don't know whether 
> > anybody has put
> > in the "setValuator" bug fix.
> > 
> > Bottom line:  if y'all will tolerate it, and if somebody will 
> > tell me how to
> > put things into CVS, I can take over the PUI development.
> > 
> > John F. Fay
> > joh...@eg...
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

RE: [Plib-devel] ssgBranch with pre and post draw callbacks

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

Steve Baker wrote:
> > Dave McClurg wrote:
> > 
> > Thanks. The change is commited to CVS
> 
> Yikes!  A little discussion first might have been nice!
> 
<snip>
> Dave - please back out that change.  It's a bad patch.
>
Done. sorry, it looked harmless.

--Dave

RE: [Plib-devel] Update TODO list

[Fay J. F C. AAC/W. <joh...@eg...>]

<begin quote>
Sorry about the delay in responding to this; I missed it the first time it
came around and just found it in the TODO list.
 
I think the problem in deleting the wrong dialog box comes from the
"puPopLiveInterface ()" call in the "puInterface" destructor.  I would
tentatively fix it by removing the call from the destructor and placing it
in the "puDeleteObject" function:
 
if ( ob->getType() | PUCLASS_INTERFACE )
  puPopLiveInterface () ;
 
I don't have any applications where dialog boxes create other dialog boxes
while destroying themselves so I can't test it out, but a look at the code
makes me think it will work.  Can someone check it out for me please?  I put
it into my own application and it doesn't seem to have broken anything.  
 
<end quote>

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


-----Original Message-----
From: Ben Woodhead [mailto:be...@bg...]
Sent: Thursday, August 31, 2000 08:24
To: 'pli...@li...'
Subject: RE: [Plib-devel] Update TODO list


Sorry, I don't have your original suggestion, I will create a section for
waiting for approval if you want to send me your original suggestion again.

Thanks Ben

> -----Original Message-----
> From: Fay John F Contr AAC/WMG [mailto:joh...@eg...]
> Sent: Thursday, August 31, 2000 10:21 AM
> To: pli...@li...
> Subject: RE: [Plib-devel] Update TODO list
> 
> 
> I put a suggested fix for the "puDeleteObject" onto the list 
> but I don't
> know whether anybody ran with it.  I also don't know whether 
> anybody has put
> in the "setValuator" bug fix.
> 
> Bottom line:  if y'all will tolerate it, and if somebody will 
> tell me how to
> put things into CVS, I can take over the PUI development.
> 
> John F. Fay
> joh...@eg...

RE: [Plib-devel] Update TODO list

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

For CVS access, you need to be a member of sourceforge, then steve can add
you as a developer in plib, once there you just need a program for
connecting to cvs and you can check in and check out files.
Otherwise you can just send updates to the list, and dave or steve will post
them for you. They maybe a good idea as well.

Later Ben

> -----Original Message-----
> From: Fay John F Contr AAC/WMG [mailto:joh...@eg...]
> Sent: Thursday, August 31, 2000 10:21 AM
> To: pli...@li...
> Subject: RE: [Plib-devel] Update TODO list
> 
> 
> I put a suggested fix for the "puDeleteObject" onto the list 
> but I don't
> know whether anybody ran with it.  I also don't know whether 
> anybody has put
> in the "setValuator" bug fix.
> 
> Bottom line:  if y'all will tolerate it, and if somebody will 
> tell me how to
> put things into CVS, I can take over the PUI development.
> 
> John F. Fay
> joh...@eg...
> 
> 
> -----Original Message-----
> From: Ben Woodhead [mailto:be...@bg...]
> Sent: Thursday, August 31, 2000 06:35
> To: 'pli...@li...'
> Subject: [Plib-devel] Update TODO list
> 
> 
> Hello Everybody
> 
> Here is a updated todo list, but I still don't have any 
> owners to any of the
> tasks. Also could someone send me information on the bug in 
> the 3ds loader.
> If you have any update please send them to me.
> 
> Thank Ben1
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] Cleaner TODO list with updates.

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

Well I got a chance to try to make the file easier to read, by shortning all
the comments. Just leaving the point.

Have a look. If theres problems let me know

Ben

RE: [Plib-devel] Update TODO list

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

Sorry, I don't have your original suggestion, I will create a section for
waiting for approval if you want to send me your original suggestion again.

Thanks Ben

> -----Original Message-----
> From: Fay John F Contr AAC/WMG [mailto:joh...@eg...]
> Sent: Thursday, August 31, 2000 10:21 AM
> To: pli...@li...
> Subject: RE: [Plib-devel] Update TODO list
> 
> 
> I put a suggested fix for the "puDeleteObject" onto the list 
> but I don't
> know whether anybody ran with it.  I also don't know whether 
> anybody has put
> in the "setValuator" bug fix.
> 
> Bottom line:  if y'all will tolerate it, and if somebody will 
> tell me how to
> put things into CVS, I can take over the PUI development.
> 
> John F. Fay
> joh...@eg...
> 
> 
> -----Original Message-----
> From: Ben Woodhead [mailto:be...@bg...]
> Sent: Thursday, August 31, 2000 06:35
> To: 'pli...@li...'
> Subject: [Plib-devel] Update TODO list
> 
> 
> Hello Everybody
> 
> Here is a updated todo list, but I still don't have any 
> owners to any of the
> tasks. Also could someone send me information on the bug in 
> the 3ds loader.
> If you have any update please send them to me.
> 
> Thank Ben1
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

RE: [Plib-devel] Update TODO list

[Fay J. F C. AAC/W. <joh...@eg...>]

I put a suggested fix for the "puDeleteObject" onto the list but I don't
know whether anybody ran with it.  I also don't know whether anybody has put
in the "setValuator" bug fix.

Bottom line:  if y'all will tolerate it, and if somebody will tell me how to
put things into CVS, I can take over the PUI development.

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


-----Original Message-----
From: Ben Woodhead [mailto:be...@bg...]
Sent: Thursday, August 31, 2000 06:35
To: 'pli...@li...'
Subject: [Plib-devel] Update TODO list


Hello Everybody

Here is a updated todo list, but I still don't have any owners to any of the
tasks. Also could someone send me information on the bug in the 3ds loader.
If you have any update please send them to me.

Thank Ben1

Re: [Plib-devel] O'Reilly: Linux Games

[Devrim E. <de...@in...>]

> Hello everybody
>
> I found an artical regarding linux gaming resources for o'reilly. I wrote to
> Terrie and he was nice enough to add plib to the list of projects.
>
> Have a look.
> Personally I think that plib is the most important gaming library that is
> open source.
> SDL - Good low-level api, but being used for porting commercial games.
>       And just incase I missed something, open source is suppost to do it
> better.
>       But games, everybody wants all the commercial games.
> Crystal Space - Increadable Engine, lots of developers but I have not seen
> one
>       playable game.
> Plib - Portable, well designed, and there are lots of great games. And they
> are all open source. Free, I will tell you, you can't ask for more.
>
> Later Ben
> ps, Does anybody know why plib so not very well known.

Poor ( ~= developers only ) web site ?

>
>
> http://www.oreillynet.com/pub/a/network/2000/08/04/magazine/linux_games.html
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

--
/*===============================================
M. Devrim Erdem            de...@in...
Software Engineering

info(+)TRON, Turkey
Tel: +90 216 4921002, Ext 138
Fax: +90 216 3432132
Http://www.infotron-tr.com
Http://abone.turk.net/mderdem
===============================================*/

RE: [Plib-devel] Update TODO list

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

Thanks Sam, 

> -----Original Message-----
> From: Sam Stickland [mailto:sa...@sp...]
> Sent: Thursday, August 31, 2000 9:48 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] Update TODO list
> 
> 
> 
> ----- Original Message -----
> From: "Ben Woodhead" <be...@bg...>
> To: <pli...@li...>
> Sent: Thursday, August 31, 2000 12:34 PM
> Subject: [Plib-devel] Update TODO list
> 
> 
> > Hello Everybody
> >
> > Here is a updated todo list, but I still don't have any 
> owners to any of the
> > tasks. Also could someone send me information on the bug in 
> the 3ds loader.
> > If you have any update please send them to me.
> >
> > Thank Ben1
> >
> >
> 
> -------------
> 
> > This is the tobe done list for plib, if you would like to add any
> > additional information to this list please e-mail me at
> > tj...@is... (Ben Woodhead).
> 
> > FEATURES
> 
> > How are these specified in ssg? I'll take a wild guess that ssg
> > doesn't manage texture environment modes (GL_MODULATE,
> > GL_DECAL etc.)
> > at all, and it only cares whether blending is on or off.
> >
> > Well, when you add a texture into an ssgSimpleState, you can either
> > pass it an 'ssgTexture' or an OpenGL texture handle - or even a
> > filename (which will result in an ssgTexture being constructed on
> > your behalf).
> >
> > Hence, there are really just two options - ssgTexture or
> > do-it-yourself.
> >
> > ssgTexture does indeed only specify GL_MODULATE - it's hard-wired in
> > the constructor function with no way to change it.
> >
> > So, do I set the required mode in a predraw callback function?
> >
> > You have (at least) five options:
> >
> > 1) Derive a new class from ssgTexture (say ssgDecalTexture) that
> > does GL_DECAL instead of GL_MODULATE.
> >
> > 2) Load the texture yourself, do the glBindTexture, set GL_DECAL
> > using glTexEnvi, pass the texture handle to SSG.
> >
> > 3) In a pre-draw callback, set the glTexEnv to GL_DECAL.
> >
> > 4) Use ssgTexture to load the texture and do either a
> > ssgSimpleState::getTextureHandle()
> > or an ssgTexture::getHandle() to get the texture handle.
> > Then you can
> > glBindTexture(handle) and change the glTexEnv setting.
> >
> > 5) Edit the SSG source code to add 'setEnvMode/getEnvMode'
> > methods to ssgTexture - then
> > contribute your change via CVS and earn fame, the
> > recognition of your peers, etc, etc.
> > While you are about it - add Mag/Min filter and texture
> > wrap options.
> >
> > People who know me well soon realise that I ALWAYS put my
> > most favored option
> > at the end of a list of choices. :-)
> >
> > Owner:
> > Importance:
> 
> It was found that the texture environment modes are global, 
> not per-texture so adding setEnvMode/getEnvMode is wrong.  The wrap
> methods and the filter methods need to be added.
> 
> The texture environment issue expanded into a far larger one 
> about state management, which is far from being resolved :)

Okey, I will leave this to dave to send me an update.
 
> > BUGS
> >
> > If the user calls "setValuator" with a pointer-to-float
> > argument and then calls it again with a pointer-to-integer
> > argument you will get some strange results.
> > Specifically, his integer variable will be overwritten with
> > the integer equivalent of his floating-point variable, both
> > immediately and whenever "getValue" is called.
> >
> > Owner:
> > Importance:
> 
> A fix for this was provided in the original email wasn't it?

Not sure if its been commited or not. Anybody know.

> > Sam Stickland posted a patch to allow PUI menu's to be 
> resized.  I havn't
> > had time to deal with that (sorry Sam)...but since he now 
> has CVS access, I
> > guess he can do it himself now.
> >
> > Owner:
> > Importance:
> 
> I added this myself some time ago - I just haven't documented 
> this yet.  Btw, it's not the menu's that get resized, it allows you to
> specify the PUI widgets in OpenGL co-ordinates rather than 
> pixel co-ordinates.  (I found this necessary because I 
> subclass some of
> the PUI widgets for use in my HUD)

Okey, I will take this out, or put it in as resolved issues unless someone
says otherwize.
 
> > OPTIMIZATION
> >
> > The new ssgVtxArray class could be made more efficient 
> (especially for GeForce
> > cards) if we added the option to pass Normal arrays as 
> 'short' or 'byte' and
> > Colour arrays as 'byte'.  At present, we have both of those 
> as 'float' - so
> > to send a vertex to T&L hardware like GeForce or Radion is 
> taking ~48 bytes.
> > If we could cut the precision, we'd only send ~27 bytes.  
> Since data transfer
> > to the card is very often the limiting factor with hardware 
> T&L, we could perhaps
> > double performance on those cards without harming non-T&L 
> cards.  The loss in
> > precision doesn't matter because normals are pretty much 
> only used for lighting -
> > which in the end produces an 8 bit result - and colours are 
> hardly every more
> > than 8 bits - even with 32 bits per pixel frame buffer depth.
> >
> > Owner:
> > Importance:
> 
> Wan't this done?

Again, I am not sure, anybody know this.

> 
> > MISC
> >
> > Documentation - this is especially problematic for SSG 
> which has undergone
> > a TON of changes since 1.0.5-ish (which is the last time I 
> did a serious
> > sync-up between the code and the manual).  The other 
> libraries aren't
> > too far out of date - but they could probably be read 
> against the header
> > files to be sure that every public function is explained 
> for every class.
> > (as a minimum).
> >
> > Owner:
> > Importance: Very high
> 
> What was the outcome of the comments in source code 
> discussion?  Did Steve decide against it?

I will have a look though the mailing list, see if i can find any info on
this.

 
> Sam
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Update TODO list

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

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Thursday, August 31, 2000 12:34 PM
Subject: [Plib-devel] Update TODO list


> Hello Everybody
>
> Here is a updated todo list, but I still don't have any owners to any of the
> tasks. Also could someone send me information on the bug in the 3ds loader.
> If you have any update please send them to me.
>
> Thank Ben1
>
>

-------------

> This is the tobe done list for plib, if you would like to add any
> additional information to this list please e-mail me at
> tj...@is... (Ben Woodhead).

> FEATURES

> How are these specified in ssg? I'll take a wild guess that ssg
> doesn't manage texture environment modes (GL_MODULATE,
> GL_DECAL etc.)
> at all, and it only cares whether blending is on or off.
>
> Well, when you add a texture into an ssgSimpleState, you can either
> pass it an 'ssgTexture' or an OpenGL texture handle - or even a
> filename (which will result in an ssgTexture being constructed on
> your behalf).
>
> Hence, there are really just two options - ssgTexture or
> do-it-yourself.
>
> ssgTexture does indeed only specify GL_MODULATE - it's hard-wired in
> the constructor function with no way to change it.
>
> So, do I set the required mode in a predraw callback function?
>
> You have (at least) five options:
>
> 1) Derive a new class from ssgTexture (say ssgDecalTexture) that
> does GL_DECAL instead of GL_MODULATE.
>
> 2) Load the texture yourself, do the glBindTexture, set GL_DECAL
> using glTexEnvi, pass the texture handle to SSG.
>
> 3) In a pre-draw callback, set the glTexEnv to GL_DECAL.
>
> 4) Use ssgTexture to load the texture and do either a
> ssgSimpleState::getTextureHandle()
> or an ssgTexture::getHandle() to get the texture handle.
> Then you can
> glBindTexture(handle) and change the glTexEnv setting.
>
> 5) Edit the SSG source code to add 'setEnvMode/getEnvMode'
> methods to ssgTexture - then
> contribute your change via CVS and earn fame, the
> recognition of your peers, etc, etc.
> While you are about it - add Mag/Min filter and texture
> wrap options.
>
> People who know me well soon realise that I ALWAYS put my
> most favored option
> at the end of a list of choices. :-)
>
> Owner:
> Importance:

It was found that the texture environment modes are global, not per-texture so adding setEnvMode/getEnvMode is wrong.  The wrap
methods and the filter methods need to be added.

The texture environment issue expanded into a far larger one about state management, which is far from being resolved :)


> BUGS
>
> If the user calls "setValuator" with a pointer-to-float
> argument and then calls it again with a pointer-to-integer
> argument you will get some strange results.
> Specifically, his integer variable will be overwritten with
> the integer equivalent of his floating-point variable, both
> immediately and whenever "getValue" is called.
>
> Owner:
> Importance:

A fix for this was provided in the original email wasn't it?

> Sam Stickland posted a patch to allow PUI menu's to be resized.  I havn't
> had time to deal with that (sorry Sam)...but since he now has CVS access, I
> guess he can do it himself now.
>
> Owner:
> Importance:

I added this myself some time ago - I just haven't documented this yet.  Btw, it's not the menu's that get resized, it allows you to
specify the PUI widgets in OpenGL co-ordinates rather than pixel co-ordinates.  (I found this necessary because I subclass some of
the PUI widgets for use in my HUD)

> OPTIMIZATION
>
> The new ssgVtxArray class could be made more efficient (especially for GeForce
> cards) if we added the option to pass Normal arrays as 'short' or 'byte' and
> Colour arrays as 'byte'.  At present, we have both of those as 'float' - so
> to send a vertex to T&L hardware like GeForce or Radion is taking ~48 bytes.
> If we could cut the precision, we'd only send ~27 bytes.  Since data transfer
> to the card is very often the limiting factor with hardware T&L, we could perhaps
> double performance on those cards without harming non-T&L cards.  The loss in
> precision doesn't matter because normals are pretty much only used for lighting -
> which in the end produces an 8 bit result - and colours are hardly every more
> than 8 bits - even with 32 bits per pixel frame buffer depth.
>
> Owner:
> Importance:

Wan't this done?

> MISC
>
> Documentation - this is especially problematic for SSG which has undergone
> a TON of changes since 1.0.5-ish (which is the last time I did a serious
> sync-up between the code and the manual).  The other libraries aren't
> too far out of date - but they could probably be read against the header
> files to be sure that every public function is explained for every class.
> (as a minimum).
>
> Owner:
> Importance: Very high

What was the outcome of the comments in source code discussion?  Did Steve decide against it?

Sam

[Plib-devel] O'Reilly: Linux Games

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

Hello everybody

I found an artical regarding linux gaming resources for o'reilly. I wrote to
Terrie and he was nice enough to add plib to the list of projects. 

Have a look.
Personally I think that plib is the most important gaming library that is
open source. 
SDL - Good low-level api, but being used for porting commercial games.
      And just incase I missed something, open source is suppost to do it
better.
      But games, everybody wants all the commercial games.
Crystal Space - Increadable Engine, lots of developers but I have not seen
one 
      playable game.
Plib - Portable, well designed, and there are lots of great games. And they
are all open source. Free, I will tell you, you can't ask for more. 

Later Ben
ps, Does anybody know why plib so not very well known. 

http://www.oreillynet.com/pub/a/network/2000/08/04/magazine/linux_games.html

[Plib-devel] Update TODO list

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

Hello Everybody

Here is a updated todo list, but I still don't have any owners to any of the
tasks. Also could someone send me information on the bug in the 3ds loader.
If you have any update please send them to me.

Thank Ben1

RE: [Plib-devel] Dragging in other libraries.

[Gouthas, T. <the...@ds...>]

Oh yeh.. thats another reason I like Plib - its self contained..
good policy..  I would'nt have bothered to check Plib out if I had to 
download a bunch of other libraries and have to build them too.


Themie

> -----Original Message-----
> From:	Steve Baker [SMTP:sjb...@ai...]
> Sent:	Thursday, August 31, 2000 3:52 PM
> To:	PLIB-devel
> Subject:	[Plib-devel] Dragging in other libraries.
> 
> Hmmm - interesting poll on LGDC today:
> 
>    "When installing a new game on my Linux system, I hate most:
> 
>        the big download                                  9.57 % (9)
>        the difficult compilation                        13.83 % (13)
>        the lack of documentation                         4.26 % (4)
>        when I don't understand the game at once          2.13 % (2)
>        when it depends on many bleeding-edge libraries  46.81 % (44)
>        when it doesn't support "make install"           13.83 % (13)
>        when it doesn't support "make uninstall"          9.57 % (9)
>                                                     Total votes: 94"
> 
> ...so it looks like the PLIB policy of not relying on any external libs
> if we can possibly avoid it is a good one.
> 
> Keeping your games cryptic and undocumented also appears to be a popular
> choice!!
> 
>      :-)
> 
> -- 
> Steve Baker   HomeEmail: <sjb...@ai...>
>               WorkEmail: <sj...@li...>
>               HomePage : http://web2.airmail.net/sjbaker1
>               Projects : http://plib.sourceforge.net
>                          http://tuxaqfh.sourceforge.net
>                          http://tuxkart.sourceforge.net
>                          http://prettypoly.sourceforge.net
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

RE: [Plib-devel] ssgBranch with pre and post draw callbacks

[Gouthas, T. <the...@ds...>]

Hi. I just stumbled across this project and well I thought I'd say hi.. this
may not be
the right mailing list but oh well sue me.

Ive spent the last week delving into the code, trying to come to terms with
it, and 
that meant going back to revising algebra long forgotten. A simple scene
graph,
it's not (well not any more). Its actually quite sophisticated, probably one
of the most
sophisticated I've seen Open sourced (thanks for that). Ive really only
played with
QVLib and Apprentice (Open Inventor clone) but apart from being seriously
buggy
none of them tackled all the key performance issues that you guys have in
Plib.

I love it, its got the best balance of sophistication, functionality and
performance 
optimisation of anything else Ive yet to come across.

Heres why I've just decided to comitt to it (and I have been researching 3D
engines
for a while now);

Its a good performer..
Its royalty free
Its open (and consequently flexible)
And from what I can tell, its well supported..

Whats my angle? Well.. I work for a comparatively poor defence research 
organisation (Australian) and my particular areas are weapon systems
analysis
and integration - (We dont build'em, we just tell the jet-jocks the best way
to 
duck'em)

Much of our work involves simulation, and much of it requires visualisation.
This ranges from doing in house analyses for our defence force sponsors or 
developing training and analysis toos for them to developing training aids
for them. 
As you can imagine, a lot of the visualisation requirements involve aircraft
and 
vehicles, terrain and often symbology to make sense of the visuals.

We cant afford the licencing of commercial visualisation libraries and
certainly 
not commercial game libraries, since we dont make any money from our
software, 
and we give our software to our sponsors or allies in co-operative projects.

So in a nut shell something like Plib is the only feasible solution, and I
feel a great 
sense of releif that finally theres something that is useful out there,
saving me the 
months, maybe years of development (and I'm sure I wouldnt produce anything
that 
comes anywhere near Plib)

So, we have lots of projects in mind, and I think Plib's just made some of
them 
feasible.

Now..  while I'm here I'll also put my 2c worth in for the code; I'm not
suggesting
anybody implements these suggestions, but thet'd certainly be nice. Oh and
I'll
also try and contribute when I can.. and as I become more familiar with it.

Okay the suggestions;

Not reflecting on its quality - I would have been nice if it had more
commenting to 
assist in someone becoming familiar with it. If time permitted, the
application of
a coding standard would go some way towards making the code easier to
understand..
for example, one coding standard mandates that all class names start in a
capital
and all member functions are preceeded by a "m". If they are pointers by an
"mp" 
all temporary variables are full lower case with underscores etc.. you get
the picture
a style which makes structure and relationships more intuitive at a glance. 

One of my pet dislikes is in-line code interspersed in declarations in the
header files
which makes them harder to read. I tend to view header files as quick
references for
member functions and variables.. and the quick reference nature of headers
is somewhat
broken by chunks of source code. What could be done is something like this;

// include definitions top half of file

int 			max;
float 		inflate(double poo);
inline int 	func(double val);

...

// inline declarations bottom half of file

inline int func(double val)
{
	return 0;
}

I've an idea for including the inline definitions in the main source along
with the rest of the
class functions leaving neat and tidy header files. If any of you are
interested I'll share my 
idea.

Replacing the math code in "sg" which consist of simple structures and
global functions
with math classes (ie J.E. Hoffmann's Math3D library)  would also go a long
way towards 
making the code simpler to follow at the expense of course of a little
performance although 
I have no feel for its quantitative impact. One fanciful future, when I
understand the code, 
and have the time (hence fanciful) I may try the comversion myself.

Oh, I have a bug fix for you too.. it was picked up by the compiler in file
ssgLoad3ds.cxx
or I think it is a bug...

Code was;

static float get(float *f) {
  if (is_little_endian)
    return *f;
  else {
    unsigned int p = (unsigned int)*f;
    endian_swap(&p);
    return p;
  }
}


I changed it to the following because the compiler flagged a warning and
after inspecting
the code I noticed you typecast the float to an int before byteswapping. the
result would
be the truncated float, byteswapped. It'd probably only manifest itself on
little endian 
machines which is why I suspect nobody's found the problem yet.

static float get(float *f) {
  if (is_little_endian)
    return *f;
  else {
    float p = *f;
    
    endian_swap((unsigned int *)&p);
    return p;
  }
}

Okay, that's about all for now, but keep up the good work.

Themie.

> -----Original Message-----
> From:	Steve Baker [SMTP:sjb...@ai...]
> Sent:	Thursday, August 31, 2000 12:29 PM
> To:	pli...@li...
> Subject:	Re: [Plib-devel] ssgBranch with pre and post draw callbacks
> 
> > Dave McClurg wrote:
> > 
> > Thanks. The change is commited to CVS
> 
> Yikes!  A little discussion first might have been nice!
> 
> > > I have a small modification to submit for plib-ssg. This consists in
> > > allowing the call of the pre and post draw callbacks for branches and
> > > not only for leaves.
> 
> There is a REASON why there are no draw callbacks on branches - and that
> is because leaf nodes that are translucent are sorted and drawn AFTER all
> the opaque ones. (For Z buffering reasons)
> 
> If you allow DRAW callbacks on branches then you have the situation where
> the branch pre-draw callback can be called - then none of the daughter
> leaf nodes drawn - and then the post-draw callback - and MUCH later have
> the nodes themselves drawn.
> 
> The only safe way to do that is to put the callbacks on the leaf nodes
> themselves.
> 
> In the future, we may also want to sort leaf nodes by material property
> (something which is rather overdue in SSG) - which would cause this
> patch to be totally unusable.
> 
> Dave - please back out that change.  It's a bad patch.
> 
> -- 
> Steve Baker   HomeEmail: <sjb...@ai...>
>               WorkEmail: <sj...@li...>
>               HomePage : http://web2.airmail.net/sjbaker1
>               Projects : http://plib.sourceforge.net
>                          http://tuxaqfh.sourceforge.net
>                          http://tuxkart.sourceforge.net
>                          http://prettypoly.sourceforge.net
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

[Plib-devel] Dragging in other libraries.

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

Hmmm - interesting poll on LGDC today:

   "When installing a new game on my Linux system, I hate most:

       the big download                                  9.57 % (9)
       the difficult compilation                        13.83 % (13)
       the lack of documentation                         4.26 % (4)
       when I don't understand the game at once          2.13 % (2)
       when it depends on many bleeding-edge libraries  46.81 % (44)
       when it doesn't support "make install"           13.83 % (13)
       when it doesn't support "make uninstall"          9.57 % (9)
                                                    Total votes: 94"

...so it looks like the PLIB policy of not relying on any external libs
if we can possibly avoid it is a good one.

Keeping your games cryptic and undocumented also appears to be a popular
choice!!

     :-)

-- 
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] Logo's.

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

OK - i've added the TuxFleet Logo (and a link) to the PLIB home page.

I should mention that if there are other projects using PLIB that
would like a mention and a link from the PLIB home page, please drop
me an email with a thumbnail image (preferably a PNG) somewhere around
80 to 120 pixels in each direction - AND the URL to link it up to.

It looks good for PLIB to have lots of excellent programs written using
it - and you just can't have too many people linking to your own
page if you want people to go there and notice it - so we all benefit.

-- 
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] "setValuator" in PUI

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

Fay John F Contr AAC/WMG wrote:
> 
> I have been looking at the "setValuator" functions in the PUI part of PLIB.
> It occurs to me that if the user calls "setValuator" with a pointer-to-float
> argument and then calls it again with a pointer-to-integer argument, he will
> get some strange results.  Specifically, his integer variable will be
> overwritten with the integer equivalent of his floating-point variable, both
> immediately and whenever "getValue" is called.
> 
> First question:  is this a problem?

Well, it's certainly a bug - I'm suprised it would ever come up - but we
should certainly fix it.

Thanks!

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] ssgBranch with pre and post draw callbacks

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

> Dave McClurg wrote:
> 
> Thanks. The change is commited to CVS

Yikes!  A little discussion first might have been nice!

> > I have a small modification to submit for plib-ssg. This consists in
> > allowing the call of the pre and post draw callbacks for branches and
> > not only for leaves.

There is a REASON why there are no draw callbacks on branches - and that
is because leaf nodes that are translucent are sorted and drawn AFTER all
the opaque ones. (For Z buffering reasons)

If you allow DRAW callbacks on branches then you have the situation where
the branch pre-draw callback can be called - then none of the daughter
leaf nodes drawn - and then the post-draw callback - and MUCH later have
the nodes themselves drawn.

The only safe way to do that is to put the callbacks on the leaf nodes
themselves.

In the future, we may also want to sort leaf nodes by material property
(something which is rather overdue in SSG) - which would cause this
patch to be totally unusable.

Dave - please back out that change.  It's a bad patch.

-- 
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] os.path module in python

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

if we still want a portable way to handle pathnames in plib, the os.path
module in python is already implemented across most platforms

http://stono.cs.cofc.edu/resources/python/lib/module-posixpath.html

maybe we should grab some code from there

-- Dave McClurg
mailto:dp...@ef...
http://mcdave.cjb.net