plib-devel

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

[Joel U. <joe...@ya...>]

Alexander Rawass wrote:
> 
> Hi,
> 
> Alexander Rawass wrote:
> >
> > <Zynism on>
> > >From the look of the plib homepage, its colors, especially the logo, you
> 
> Dear Steve, that's a thing I really mean:
> 
> I really don't like the colors of your homepage, I see yellow text on
> green with
> green marble bitmap underneath - it's a don't care for the entry page
> for me,
> but what *really* *sucks* are the colors of the documentation - at least
> there, you should choose better colors or none at all, every time I go
> on
> plib homepage to look if docu has changed, I have to fiddle around with
> brightness and contrast to be able to read anything - *please* change
> the colors at least there.

Actually I quite like them - the yellow could be a little brighter
though. I agree that the web page does look basic when you first come
across it - I have to say I dismissed it the first time I saw it, as
other libraries I was looking at like clanlib, sdl, and crystal space
had flashier web pages. I've gotten quite used to it now though...

> Another improvement for plib-homepage:
> 
> Pre-built binaries for all platforms/os that plib can be build for.
> I really like it when people do that.
> That reminds me to compile tuxfleet-0.3.0 as well on beos as on aix and
> solaris,
> I could do plib-binaries for them if you don't want to, but I have no
> access be able to compile for other os/platforms.

I know Steve's not a big fan of pre-compiled binaries, but these would
have helped me when I first started. Maybe with the sourceforge compile
farm, and a script, binaries could be made for several systems with one
simple command (?) Has Wolfram figured out how to use it yet ?

Bye - Joel.

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

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

Hi,

Alexander Rawass wrote:
> 
> <Zynism on>
> >From the look of the plib homepage, its colors, especially the logo, you

Dear Steve, that's a thing I really mean:

I really don't like the colors of your homepage, I see yellow text on
green with
green marble bitmap underneath - it's a don't care for the entry page
for me,
but what *really* *sucks* are the colors of the documentation - at least
there, you should choose better colors or none at all, every time I go
on
plib homepage to look if docu has changed, I have to fiddle around with
brightness and contrast to be able to read anything - *please* change
the colors at least there.

Another improvement for plib-homepage:

Pre-built binaries for all platforms/os that plib can be build for.
I really like it when people do that.
That reminds me to compile tuxfleet-0.3.0 as well on beos as on aix and
solaris,
I could do plib-binaries for them if you don't want to, but I have no
access be able to compile for other os/platforms.


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-devel] O'Reilly: Linux Games

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

Hi,

Ben Woodhead wrote:
> 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.

What do the people from Loki games do, when they want to 3D?
Do they use GL directly, have they a - secrect - highlevel scenegraph
like
plib, will it get into SDL (or another library) some day?

I just got a demo disk with demo games from Loki on on it:

Descent3:
-rw-r--r--   1 alex     users        7029 Aug 19 04:56 FAQ.demo
-rw-r--r--   1 alex     users        6220 Aug 19 04:56 README
drwxr-xr-x   6 alex     users        1024 Aug 19 04:56 custom
-rw-r--r--   1 alex     users     8899313 Aug 19 04:56 d3-linux.hog
-rw-r--r--   1 alex     users    53956800 Aug 19 04:56 d3demo.hog
drwxr-xr-x   2 alex     users        1024 Aug 19 04:56 demo
-rwxr-xr-x   1 alex     users     3127688 Aug 19 04:56 descent3_demo
-rw-r--r--   1 alex     users      278329 Aug 19 04:56 extra13.hog
drwxr-xr-x   2 alex     users        1024 Aug 19 04:56 missions
drwxr-xr-x   2 alex     users        1024 Aug 19 04:56 netgames
drwxr-xr-x   2 alex     users        1024 Aug 19 04:56 online
-rw-r--r--   1 alex     users     5611278 Aug 19 04:56 ppics.hog
alex@annika:/vast2/games/descent3_demo > ldd ./descent3_demo 
        libdl.so.2 => /lib/libdl.so.2 (0x40024000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40028000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40039000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4010f000)
        libm.so.6 => /lib/libm.so.6 (0x4011e000)
        libc.so.6 => /lib/libc.so.6 (0x4013a000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Descent hides everything?

Heavy Gear 2:
alex@annika:/vast2/games/hg2_demo > dir|grep -i lib
-rwxrwxr-x   1 alex     users     2293060 Aug 19 04:57
libMesaVoodooGL.so.1.2.030300
-rwxr-xr-x   1 alex     users      883017 Aug 19 04:57 libSDL-1.1.so.0
-rwxr-xr-x   1 alex     users       93986 Aug 19 04:57
libSDL_mixer-1.0.so.0
-rwxr-xr-x   1 alex     users      297936 Aug 19 04:57 libnetwork.so
-rwxr-xr-x   1 alex     users      120064 Aug 19 04:57 libopenal.so
-rwxr-xr-x   1 alex     users     2381228 Aug 19 04:57 libshell.so
-rwxr-xr-x   1 alex     users     2685132 Aug 19 04:57 libsim.so

Are libnetwork, libshell, libsim private to Loki or public?

-rwxr-xr-x   1 alex     users      905792 Aug 19 04:57 libsmpeg-0.4.so.0
alex@annika:/vast2/games/hg2_demo > ldd ./hg2stub 
        libSDL-1.1.so.0 => /usr/lib/libSDL-1.1.so.0 (0x40024000)
        libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x400b4000)
        libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x400b7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x400db000)
        libdl.so.2 => /lib/libdl.so.2 (0x400ec000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400ef000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401c5000)
        libz.so.1 => /usr/X11R6/lib/libz.so.1 (0x401d5000)
        libnetwork.so => not found
        libm.so.6 => /lib/libm.so.6 (0x401e5000)
        libc.so.6 => /lib/libc.so.6 (0x40201000)
        libesd.so.0 => /usr/lib/libesd.so.0 (0x402e8000)
        libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x402ed000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Aha - more too see and learn :-)

>       But games, everybody wants all the commercial games.
> Crystal Space - Increadable Engine, lots of developers but I have not seen
> one
>       playable game.

I had a look at crystal space some months ago, but at that date the
archive
was (in my opinion) a mess, no good doku, I think.

In some days/weeks, I' send them an email telling them something like
'If you want TuxFleet to optionally use CrystalSpace/CrystalClear as
scenegraph/
3D renderer, please have a look at class FleetScene/FleetSceneSSG and
re-implement
this class as FleetSceneCrystal. see
tuxfleet.sourceforge.net/doxygen/html/class_FleetScene.html
Thank you.'

But I suspect that they're probably very very happy in having written
the best
ego-shooter-scenegraph, so they need no games to prove it :-)

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

Are there even more than there are logos on the plib page?

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

Yes. Lack of advertisement.

<Zynism on>
>From the look of the plib homepage, its colors, especially the logo, you
don't
come to think that it's anything work, or that it's made by a
professional.

If you want the surfers to recognize that, do the following:
a) get a better logo for plib (at least tga, 800x600, 24 Million
blistering
colors, with transparency effects and possibly animated
b) supply your docs as PDF
c) use a pixel-editing-homepage-construction-tool to make your homepage
d) use a lot of frames
e) make the logos of the games move with flash on the screen
f) don't supply docs
g) use cool words

You get the idea.
<Zynism off>


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-devel] ssgBranch with pre and post draw callbacks

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

"Gouthas, Themie" wrote:

> >Well, the performance is not the only penalty.  We do things like having
> >arrays of vertex data that's passed directly to OpenGL.  If you wrap them
> >in classes then you'll get virtual table pointers and such between the
> >variable definitions...that would be a serious problem.
> >
> >As I've said before, the SG library is really only there for the benefit
> >of SSG's internals.  An 'application level' geometry library could be made
> >in glorious C++ that used SG as it's 'work-horse' - but I wouldn't want
> that
> >inside SSG.
> 
> Again, I see your point.. as I said, quantitative feel for performance is what I was
> lacking and I've never really assessed the performance degradation of virtual
> table pointers.

It's not so much the performance of virtual functions called via the vtable - it's
that if you took (say) an sgVec3 - and wrapped it into a class with one or more
virtual functions - then the compiler would tack on a pointer at the end of
every sgVec3 you declared.

That's a 33% increase in memory consumption for those huge vertex tables (serious)
and worse still, it means that if you declare an array of sgVec3's (such as we
do for ssgVtxArray for example) then there would be 4 byte gaps between each
set of 3 floats.  That's *really* ugly from an OpenGL perspective.

There is a place for C++ classes (and I'm a BIG fan of C++ classes) - but you have
to know when and where to stop and revert to the simplicity of C....the interface
with OpenGL is a place where it's *critical* that you know where each byte is - and
C++ makes that a tricky proposition.

> And on bugs...
> 
> So far, Ive had some negative experiences with some of the model loaders,
> particularly the 3ds and dxf. I'll elaborate when I've experimented some
> more

Yes - I think we are aware that several of the loaders need some significant
work still.

Writing good loaders is a tricky proposition...but having good loaders is
what separates the men from the boys when it comes to scene graph API's.

I think the impetus provided by PrettyPoly (http://prettypoly.sourceforge.net)
...when it eventually appears...will spur people into working out the kinks
from the loaders and writers.

-- 
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] Cleaner TODO list with updates.

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

"Gouthas, Themie" wrote:
> 
> Regarding an entry in the TO DO list. I'm thinking about surically removing
> Curt Olson's SKY model from FSGear, if I am successful I'll post it here.

Curt has already done most of the work...we just need to nudge it over the
next couple of hurdles.

> I intend to simplify it to a flat earth model, and simplify its set up
> perhaps
> with say a north facing vector and time of day initialisation. Its a better
> sky model than a lot of commercial programs have.

I think it would be a shame to make it incompatible with FGFS in this way.
It's in everyone's interest to try to keep the same chunk of code running
in both setups - so that once the sky model is inside PLIB, FGFS can use
it and dump their own copy of the code.

Actually - I don't believe that switching cloud models to flat earth
is actually a simplification...if they don't curve with the shape
of the earth then the clouds don't meet the terrain at the horizon.

> Same would be nice for terrain but that's way too for me complex to
> comprehed at this early stage.

Yes - and I think that's outside the scope of PLIB anyway.

Once again, Curt is ahead of you.  He's split all the complex
terrain tools and rendering code out of FGFS and placed it into
the 'TerraGear' project.

I think it's pointless (and counterproductive) to merge those tools
into PLIB.

The sky is a good choice of package because nearly every 3D game
could use a good sky - and the increase to the size of the PLIB
download wouldn't be significant.

However, the Terragear stuff is unique to modelling the 21st
century Earth - viewed from an altitude of thousands of feet,
at speed in the zero to 1000mph range - and with special emphasis
on airfields that are way out of proportion to their general
significance in the scenery.

That's really only relevent to a couple of game genre's...and
the additional download would be out of all proportion to it's
value to the majority of games.

...aside from which - Curt might not want to do that...for which
I couldn't fault him!

-- 
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] A question regarding model loaders

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

Those of you who have had more extensive experience, which 3D model loaders
are most completely implemented and bug free?

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

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

Regarding an entry in the TO DO list. I'm thinking about surically removing 
Curt Olson's SKY model from FSGear, if I am successful I'll post it here.

I intend to simplify it to a flat earth model, and simplify its set up
perhaps 
with say a north facing vector and time of day initialisation. Its a better 
sky model than a lot of commercial programs have.

Same would be nice for terrain but that's way too for me complex to
comprehed 
at this early stage.

> -----Original Message-----
> From:	Ben Woodhead [SMTP:be...@bg...]
> Sent:	Friday, September 01, 2000 2:58 AM
> To:	'pli...@li...'
> Subject:	RE: [Plib-devel] Cleaner TODO list with updates.
> 
> Thanks for the update dave, I changed the file to meet your updates.
>  
> Later Ben
> ps Attached is the new copy. 
> 
> 	-----Original Message-----
> 	From: Dave McClurg [mailto:Dav...@dy...]
> 	Sent: Thursday, August 31, 2000 2:09 PM
> 	To: 'pli...@li...'
> 	Subject: RE: [Plib-devel] Cleaner TODO list with updates.
> 	
> 	
> 
> 	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> 
>  << File: PLIBTODO.txt >> 

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

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

>> One of my pet dislikes is in-line code interspersed in declarations in
the
>> header files which makes them harder to read.

>Well, that's also a personal matter.  I dislike having the code for a class
>scattered all over the place.  I can't avoid separating out the non-inline
>code from the inlines and the declarations - but as for the rest, I like
>to keep it all close together.

Fair enough. I tend to concentrate my inline function bodies at the end of
the header file, and leave inline function prototypes in their rightful
place
within the class definitions. Its just how I prefer to read my code.

>> 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.
>
>Well, the performance is not the only penalty.  We do things like having
>arrays of vertex data that's passed directly to OpenGL.  If you wrap them
>in classes then you'll get virtual table pointers and such between the
>variable definitions...that would be a serious problem.
>
>As I've said before, the SG library is really only there for the benefit
>of SSG's internals.  An 'application level' geometry library could be made
>in glorious C++ that used SG as it's 'work-horse' - but I wouldn't want
that
>inside SSG.

Again, I see your point.. as I said, quantitative feel for performance is
what I was 
lacking and I've never really assessed the performance degradation of
virtual
table pointers.

And on bugs...

So far, Ive had some negative experiences with some of the model loaders,
particularly the 3ds and dxf. I'll elaborate when I've experimented some
more

> -----Original Message-----
> From:	Steve Baker [SMTP:sjb...@ai...]
> Sent:	Friday, September 01, 2000 6:44 AM
> To:	pli...@li...
> Subject:	Re: [Plib-devel] ssgBranch with pre and post draw callbacks
> 
> "Gouthas, Themie" wrote:
> > 
> > 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.
> 
> No - this is the *perfect* list for efflusive complements and good bug
> fixes!
> 
> > Its a good performer..
> 
>   ...it's not bad - but we could do better.
> 
> > Its royalty free
> 
>   ...indeed.
> 
> > Its open (and consequently flexible)
> 
>   ...but of course!
> 
> > And from what I can tell, its well supported..
> 
>   ...yes - what started as a solo project has developed a large
>   development team.  That's what I always hoped would happen - but
>   it's take an while to get there.
>  
> > 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..
> 
> ...yes - I'm guilty of that.  I dislike reading comments because they
> are sometimes out of date - and there is nothing worse than trying to
> understand code when you have been given the wrong idea of how it works.
> 
> But I'm aware that most people don't feel that way - and some more
> comments would be handy.
> 
> > 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.
> 
> ...well, I follow the OpenGL scheme - where all global symbols start with
> a (hopefully unique) two or three letter prefix.
> 
> I truly loath and detest putting prefixes on member variables...but there
> are dozens and dozens of coding "standards" in the world - and each to his
> own.
> 
> > One of my pet dislikes is in-line code interspersed in declarations in
> the
> > header files which makes them harder to read.
> 
> Well, that's also a personal matter.  I dislike having the code for a
> class
> scattered all over the place.  I can't avoid separating out the non-inline
> code from the inlines and the declarations - but as for the rest, I like
> to keep it all close together.
> 
> > 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.
> 
> I don't find that to be a problem...in fact, I like to have the code right
> there because reading it is easier than reading documentation for the
> function.
> 
> > 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;
> > }
> 
> Not gonna happen I'm afraid.  I like it the way it is...sorry!
>  
> > 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.
> 
> Well, the performance is not the only penalty.  We do things like having
> arrays of vertex data that's passed directly to OpenGL.  If you wrap them
> in classes then you'll get virtual table pointers and such between the
> variable definitions...that would be a serious problem.
> 
> As I've said before, the SG library is really only there for the benefit
> of SSG's internals.  An 'application level' geometry library could be made
> in glorious C++ that used SG as it's 'work-horse' - but I wouldn't want
> that
> inside SSG.
> 
> > One fanciful future, when I understand the code,
> > and have the time (hence fanciful) I may try the comversion myself.
> 
> By all means build a wrapper around SG - or create an entirely new
> library with hooks to extract the raw vertex/matrix data for SSG...but
> please don't try to inflict it onto SSG itself - it doesn't need that
> sophistication - and it would suffer greatly in complexity as a result.
> 
> > Oh, I have a bug fix for you too.. it was picked up by the compiler in
> file
> > ssgLoad3ds.cxx
> 
> Dunno - this is Dave's terratory.
> 
> I've run *most* of SSG and the rest of PLIB on SGI machines - and it works
> fine - but none of my own applications load 3DS files - so this is a bug
> that would have slipped through the cracks!
> 
> -- 
> 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] Update TODO list again!

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

Steve wrote:
> OK - I've enabled the Bug tracker and the Project/Task 
> manager (Aka To-Do List).
>
Thanks!
I entered all the tasks on Ben's list into sourceforge.

--Dave

[Plib-devel] Quaternion vs Euler demo

[Michael K. <mk...@fu...>]

Hi everyone,

 Dave McClurg asked me to submit a Quaternion demo and send a little note to
the list.

 I made a demo last night that shows the differences between a cube rotating
via euler rotation, and a cube rotating via quaternion rotation. Dave
submited it last night and you can check it out from here:

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/plib/examples/src/sg/sg_quat_t
est.cxx?cvsroot=plib


 I think its fairly self-documented, but then again I'm not approaching it
from zero-knowledge. If anyone has questions feel free to ask and I will try
to help out and add any comments to the source as needed.


Michael Kurth

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

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

Fay John F Contr AAC/WMG wrote:
> 
> Negative on your question of always liking my last suggestion.  I would go
> with your proposal:
> 
> #ifdef _PU_USE_GLUT_WINDOWS
> int puGetWindow () { return glutGetWindow () ; }
> #else
> int puGetWindow () { return 0 ; }
> #endif
> 
> Would there be an impact to making it an inline function?  It would speed
> execution and reduce program size slightly on the one hand, but would
> require that the function itself be placed in the header file.  My personal
> preference would be to make it inline.

It's such a tiny function - I don't think it matters.  The compiler
would optimise an 'inline' down to just '0' or a call to glutGetWindow - so
there is no inline overhead to consider.

OTOH, I suppose that if ALL such functions were off in the library then there
would be less risk of a program that's compiled one way linking to a library
that's compiled the other way.

Really, we should make PLIB 100% independent of GLUT - so make the application
tell us the current Window if we need to know it.

-- 
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] Cleaner TODO list with updates.

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

Fay John F Contr AAC/WMG wrote:
> 
> First question:  which would be better:
> 
> (1) Put into "pu.h", inside one of the "PU_NOT_USING_GLUT" blocks:
> 
> int glutGetWindow () { return 0 ; }  /* Mimic the GLUT get window function
> */

I would have thought (in pu.cxx):

  int puGetWindow ()
  {
  #ifdef PU_NOT_USING_GLUT
    return 0 ;
  #else
    return glutGetWindow () ;
  #endif
  }

with:

  extern int puGetWindow () ;

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

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

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

Ben Woodhead wrote:

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

Well, it only has to be known to game developers - and judging
by the fact that there are LOTS of games that use PLIB and fewer
that use the "more well known" libraries - we must conclude
that the right people DO know about us.
 
One possible reason for use being less well known is that
the CrystalSpace guys are also prominent in the LGDC group...
that runs a pretty major game writers mailing list.

To be honest, I'm not too concerned about the public prominance
of PLIB - so long as the people who need it can find it.

Devrim Erdem wrote:

> Poor ( ~= developers only ) web site ?

What do we care about non-developers.  End users  (games players)
couldn't care less about engine does what.  We only have to appeal
to games developers.

-- 
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] Update TODO list

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

Ben Woodhead wrote:
> 
> 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.

Hmmm - isn't there a 'To Do' list thingy in Sourceforge?  Maybe we should use
it...but then maybe I'm imagining it.

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

Yes - these things can be deceptive.  That's why we need
to talk a little about 'enhancements' - even if they seem
easy and "obvious"!

No harm done anyway.

...CVS, we luv U...  :-)

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

"Gouthas, Themie" wrote:
> 
> 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.

No - this is the *perfect* list for efflusive complements and good bug fixes!

> Its a good performer..

  ...it's not bad - but we could do better.

> Its royalty free

  ...indeed.

> Its open (and consequently flexible)

  ...but of course!

> And from what I can tell, its well supported..

  ...yes - what started as a solo project has developed a large
  development team.  That's what I always hoped would happen - but
  it's take an while to get there.
 
> 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..

...yes - I'm guilty of that.  I dislike reading comments because they
are sometimes out of date - and there is nothing worse than trying to
understand code when you have been given the wrong idea of how it works.

But I'm aware that most people don't feel that way - and some more
comments would be handy.

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

...well, I follow the OpenGL scheme - where all global symbols start with
a (hopefully unique) two or three letter prefix.

I truly loath and detest putting prefixes on member variables...but there
are dozens and dozens of coding "standards" in the world - and each to his
own.

> One of my pet dislikes is in-line code interspersed in declarations in the
> header files which makes them harder to read.

Well, that's also a personal matter.  I dislike having the code for a class
scattered all over the place.  I can't avoid separating out the non-inline
code from the inlines and the declarations - but as for the rest, I like
to keep it all close together.

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

I don't find that to be a problem...in fact, I like to have the code right
there because reading it is easier than reading documentation for the function.

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

Not gonna happen I'm afraid.  I like it the way it is...sorry!
 
> 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.

Well, the performance is not the only penalty.  We do things like having
arrays of vertex data that's passed directly to OpenGL.  If you wrap them
in classes then you'll get virtual table pointers and such between the
variable definitions...that would be a serious problem.

As I've said before, the SG library is really only there for the benefit
of SSG's internals.  An 'application level' geometry library could be made
in glorious C++ that used SG as it's 'work-horse' - but I wouldn't want that
inside SSG.

> One fanciful future, when I understand the code,
> and have the time (hence fanciful) I may try the comversion myself.

By all means build a wrapper around SG - or create an entirely new
library with hooks to extract the raw vertex/matrix data for SSG...but
please don't try to inflict it onto SSG itself - it doesn't need that
sophistication - and it would suffer greatly in complexity as a result.

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

Dunno - this is Dave's terratory.

I've run *most* of SSG and the rest of PLIB on SGI machines - and it works
fine - but none of my own applications load 3DS files - so this is a bug
that would have slipped through the cracks!

-- 
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] Update TODO list again!

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

> Ben Woodhead wrote:
> 
> Sounds like a good idea, I will check that out. And you are welcome.

OK - I've enabled the Bug tracker and the Project/Task manager (Aka To-Do List).

I've granted all existing developers "Tech Only" access privilages to both of those
things.  Since Dave seems to be de'facto 2nd in charge here - he has Admin privilages
too.

-- 
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] Cleaner TODO list with updates.

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

Negative on your question of always liking my last suggestion.  I would go
with your proposal:
 
#ifdef _PU_USE_GLUT_WINDOWS
int puGetWindow () { return glutGetWindow () ; }
#else
int puGetWindow () { return 0 ; }
#endif
 
Would there be an impact to making it an inline function?  It would speed
execution and reduce program size slightly on the one hand, but would
require that the function itself be placed in the header file.  My personal
preference would be to make it inline.
 

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

 
-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Thursday, August 31, 2000 16:16
To: 'pli...@li...'
Subject: RE: [Plib-devel] Cleaner TODO list with updates.



If you like (1), go for it.  It sounds cleaner.  The only problem I see is a
linking error if you don't want PUI to use glut but you are still using it
elsewhere in your app.  You could fix that by defining

#ifdef _PU_USE_GLUT_WINDOWS 
int puGetWindow () { return glutGetWindow () ; } 
#else 
int puGetWindow () { return 0 ; } 
#endif 

Or do you always prefer the last option you give like Steve? 

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

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

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

If you like (1), go for it.  It sounds cleaner.  The only problem I see is a
linking error if you don't want PUI to use glut but you are still using it
elsewhere in your app.  You could fix that by defining

#ifdef _PU_USE_GLUT_WINDOWS
int puGetWindow () { return glutGetWindow () ; }
#else
int puGetWindow () { return 0 ; }
#endif

Or do you always prefer the last option you give like Steve?

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


> First question:  which would be better:
>  
> (1) Put into "pu.h", inside one of the "PU_NOT_USING_GLUT" blocks:
>  
> int glutGetWindow () { return 0 ; }  /* Mimic the GLUT get 
> window function
> */
>  
> (2) Put several (one to two dozen) instances of "_PU_USE_GLUT_WINDOWS"
> blocks
>  
> 
> John F. Fay 
> joh...@eg... 

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

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

First question:  which would be better:
 
(1) Put into "pu.h", inside one of the "PU_NOT_USING_GLUT" blocks:
 
int glutGetWindow () { return 0 ; }  /* Mimic the GLUT get window function
*/
 
(2) Put several (one to two dozen) instances of "_PU_USE_GLUT_WINDOWS"
blocks
 

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

 
-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Thursday, August 31, 2000 12:32
To: 'pli...@li...'
Subject: RE: [Plib-devel] Cleaner TODO list with updates.



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... <mailto:dp...@ef...>  
http://mcdave.cjb.net <http://mcdave.cjb.net>  

RE: [Plib-devel] SSG bux fixes for untextured .3ds objects

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

The message below was posted on Mon 8/14/00 10:32 AM.  The period for
comment is over. :)

These changes look good to me and they only affect ssgSimpleState.cxx.  I
committed the changes to CVS and did some testing. 
Let me know if there are problems.

--Dave

Dan Gelb wrote:
> Last week I posted on plib-users about problems I was having 
> with .3ds objects
> that were not textured.  I figured out a couple changes that 
> solved the problems
> for me, and I'm assuming this is the right place to post them.
> 
> 1. Non-textured objects show up as white when textured 
> objects drawn before them.
> 
> I started with the tux ssg example program.  One of the 
> textured objects drawn
> sets the GL_EMISSION material values to 1.0,1.0,1.0.  When 
> the .3ds objects are
> drawn without textures it sets the ambient, diffuse, and 
> specular material properties,
> but doesn't set the emissive back to 0.0.  I added a line to 
> ssgSimpleState::apply
> to set it to 0.0 if it isn't specified.  I don't know if this 
> is the correct place or
> not.
> 
> 2. First non-textured object always shows up as white in 
> scene with or without textures
> 
> I believe this was happening because 
> glDisable(GL_COLOR_MATERIAL) is called AFTER
> the glMaterial calls in ssgSimpleState::apply.  This causes 
> the glMaterial calls
> to be ignored for the first object, but work for subsequent 
> objects.  I think that is
> what happens.  My workaround was to move the ssgDisableTable 
> call to before
> the glMaterial calls.
> 
> I don't know if either of these is the proper solution, or if 
> they would break
> other areas.  They seemed to work for me though.
> 
> Dan

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

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

I'll get onto it.
Oh, please disregard the question in my previous post about
"puPopLiveInterface" taking an argument.  I went and looked at your e-mail
again.
 

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

 
-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Thursday, August 31, 2000 12:32
To: 'pli...@li...'
Subject: RE: [Plib-devel] Cleaner TODO list with updates.



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... <mailto:dp...@ef...>  
http://mcdave.cjb.net <http://mcdave.cjb.net>  

RE: [Plib-devel] Update TODO list

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

Ouch!  My mistake, putting in "or" instead of "and" in the logic.
Does "puPopLiveInterface" take an argument?  It doesn't in the version I am
using.
 
I brought the matter up because it was still in the TODO list.
 

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

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



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

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

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

Sounds like a good idea, I will check that out. And you are welcome.
 
Later Ben

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Thursday, August 31, 2000 3:08 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 
> 
> 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 

Good idea.  You should get Steve to make you a developer and then use the
sourceforge "Tasks" section to track all this.  For an example, see:

http://sourceforge.net/pm/?group_id=649
<http://sourceforge.net/pm/?group_id=649>  

Thanks again for doing this. 

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

Good idea.  You should get Steve to make you a developer and then use the
sourceforge "Tasks" section to track all this.  For an example, see:

http://sourceforge.net/pm/?group_id=649

Thanks again for doing this.

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