plib-devel

RE: [Plib-devel] PUI questions

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

John wrote:
> I am working on a CFD grid generation program that makes very 
> heavy use of
> PUI.  I've had to add several new widgets, multiple-window 
> capability, and
> active-widget callbacks, so I call it "PUI-incremented" 
> privately.  The
> program has some 45 windows, averaging one or two dozen 
> widgets each.  I
> have just started upgrading it to PUI 1.3.0 (note my previous 
> posting on
> this list about adding multiple-window capabilities).
>
As for using multiple glut windows, I have mixed feelings.  I'm developing
for an embedded system that doesn't have support for multiple glut windows.
By "multiple interfaces linked together" i mean when you click on a button
it takes you to a *new* interface by deleting the *old* interface and
creating a new one in the same window.

> I haven't used rendering callbacks.  My "puLargeInput" is 
> basically a slider
> with a list box (and I use it for file listing and selection), but it
> doesn't work quite right and should probably be implemented 
> differently from
> the way I have done it.  I'm not sure what you mean by 
> "multiple interfaces
> linked together" but if you mean multiple windows I can 
> certainly help you.
> And I don't know what a python is, aside from a particularly 
> large snake.
>
information about python can be found here -- www.python.org.  using
scripting to drive your interface system is becoming pretty common.

i know that PUI is considered fairly static and stable but would anyone mind
some refinement of PUI to occur.  basically, my goal would be to enhance PUI
to the point where i can build a nice looking SSG viewer.  For that, I need
a listbox and other controls (which could be in the viewer) to allow
something that looks as good as GLUI example #5.  Any reason not to go
forward in this direction?

--Dave

RE: [Plib-devel] PUI questions

[John F. F. <joh...@eg...>]

I am working on a CFD grid generation program that makes very heavy use of
PUI.  I've had to add several new widgets, multiple-window capability, and
active-widget callbacks, so I call it "PUI-incremented" privately.  The
program has some 45 windows, averaging one or two dozen widgets each.  I
have just started upgrading it to PUI 1.3.0 (note my previous posting on
this list about adding multiple-window capabilities).

I haven't used rendering callbacks.  My "puLargeInput" is basically a slider
with a list box (and I use it for file listing and selection), but it
doesn't work quite right and should probably be implemented differently from
the way I have done it.  I'm not sure what you mean by "multiple interfaces
linked together" but if you mean multiple windows I can certainly help you.
And I don't know what a python is, aside from a particularly large snake.

Does anybody else on this list use PUI?

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


-----Original Message-----
From: Dave McClurg [mailto:da...@po...]
Sent: Saturday, July 29, 2000 10:49
To: pli...@li...
Subject: [Plib-devel] PUI questions


I'm just starting to use PUI and I've looked at complex.cxx.
http://plib.sourceforge.net/pui/index.html doesn't seem to work.

Is there any project that makes heavy use of PUI?
rendering callbacks, sliders with list boxes, multiple interfaces
that are linked together, python driven pui scripting

I want to start by making a file requestor (slider + listbox)
i didn't see a listbox widget.  would i use a "frame"?

btw, did pli...@li... ever recover?
i had to un-subscribe because of all those auto-responder messages

--
Dave McClurg
dav...@dy...     http://www.dynamix.com
da...@po... (home)        http://www.pond.net/~davem


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

Re: [Plib-devel] PLIB 'Neat stuff' library

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

Christian Mayer wrote:
> 
> Steve Baker wrote:
> >
> > One nasty issue that raises is how you'd load (say) VRML files
> > without linking in the Aux library if your game didn't WANT to
> > see spheres and cubes and things as anything other than
> > a bunch of tristrips...Hmmmmm.
> 
> All 'complex primitives' like spheres and cubes need a way to convert
> themselfs to tristrips. First they need it to be able to be displayed
> and secondly anyone who doesn't like these primitves in his scenegraph
> would convert them and dump them.

We talked about this at length on the PPE list a while back.

I think that what we should do is to derive a class from ssgRangeSelector
to implement these objects.

As the file is loaded, it could have various polygonal versions created
as leaf nodes by default - at various levels of detail.  We might perhaps
want some global 'error metric' control for the creation of those things...
but perhaps not in the first version.

Thus, programs that don't know about VRML would be able to traverse
the scene graph without needing to know about spheres and cones and
such like. Programs that do care can take appropriate action.

When the model is written out, a VRML or POV file writer need
only to look at the type of that node to realise that it shouldn't write
out the underlying geometry - but instead to emit a simple sphere, cone,
etc.  Writers for formats like AC3D that don't have higher level primitives
would simply write out the underlying geometry in the normal way - which
is the best you can do under the circumstances.

The bottom line is that a typical game can still read VRML files without
having to worry about high level primitives - there is no realtime
penalty to using them - and yet programs like modellers can still identify
those nodes and do more sophisticated things.

> So anyone who needs to be able to read VRLM needs to use the Aux library
> - and if it is only for converting the primitives ASAP.

I suppose so.

> I don't think that that limitation is a too big. Esp. as you could
> convert the models to something else before loading them if you don't
> like the bloat of an Aux library.

Yes.

-- 
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] PLIB 'Neat stuff' library

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

Christian Mayer wrote:
> 
> Dave McClurg wrote:
> >
> > right now, http://plib.sourceforge.net has a few links to the more
> > prominent projects that use plib.
> 
> Does Majik3d still use PLIB? They had an anouncement that they are using
> a commercial 3d library now...

Really?  They didn't mention anything about that to me.

I'll check it out.

-- 
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] PLIB 'Neat stuff' library

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

Steve Baker wrote:
> 
> One nasty issue that raises is how you'd load (say) VRML files
> without linking in the Aux library if your game didn't WANT to
> see spheres and cubes and things as anything other than
> a bunch of tristrips...Hmmmmm.

All 'complex primitives' like spheres and cubes need a way to convert
themselfs to tristrips. First they need it to be able to be displayed
and secondly anyone who doesn't like these primitves in his scenegraph
would convert them and dump them.

So anyone who needs to be able to read VRLM needs to use the Aux library
- and if it is only for converting the primitives ASAP.

I don't think that that limitation is a too big. Esp. as you could
convert the models to something else before loading them if you don't
like the bloat of an Aux library.

CU,
Christian

Re: [Plib-devel] PLIB 'Neat stuff' library

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

Dave McClurg wrote:
> 
> right now, http://plib.sourceforge.net has a few links to the more
> prominent projects that use plib.  

Does Majik3d still use PLIB? They had an anouncement that they are using
a commercial 3d library now...

CU,
Christian

Re: [Plib-devel] PLIB 'Neat stuff' library

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

Dave McClurg wrote:

> any idea when we might see the sky code in auxlibs?

Well, Curt's code is in his own SimGear package - and still
needs to have a little pruned out (or faked in) to make it
work with non-SimGear packages (We certainly don't want to
add a dependancy on SimGear withing PLIB).  On the other hand,
having removed that stuff, the new ssgSky would be no use to
programs needing the sophisticated ephemeris stuff - FlightGear
for example.

That implies putting a fork in Curt's sky code development...
which is a really nasty thing to do - two completely separate
copies of the code being maintained and developed - FlightGear
users having two copies of essentially the same code lying around...
YUK!  I can't help feeling that there must be a way to resolve that -
but until I've had a chance to rummage around in that stuff, I
can't say how hard that will prove to be.

I think that the major remaining issue is that the position
of sun, moon and stars comes from a sophisticated astronomical
model.  99% of applications won't need that - so something
*really* simple like azimuth/elevation for sun and moon and
random positioning for stars will be plenty.  I don't want
the astronomy code inside PLIB - it's wildly "off-topic"...
but SimGear NEEDS that sophisticated interface.

Ultimately, games will want to have sky models with green
clouds and a purple sky with a blue sun and orange stars...
there will need to be hooks to do crazy stuff like that too.

Meantime, if anyone needs Sky code - just grab a copy of SimGear.

Right now, I'm giving PPE my undivided attention - so looking
deeper into the sky stuff will just have to wait.  I have a little
hack to put into the SSG file format loader/saver so we can use it
for 'UNDO' in PPE - but that's all I plan to do to PLIB for a
few weeks.

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

RE: [Plib-devel] PLIB 'Neat stuff' library

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

> > ok. so we add 'tools' and 'auxlibs'.
> 
> Yep.  I've just committed those  :-)
> 
thanks!

> Do you actually have specific tools and auxlibs that you want
> to commit?   If so, I'd better create the directories for
> those too.
>
not yet.  i'm cooking a few things and
i'll ask for help when i need new directories.

any idea when we might see the sky code in auxlibs?

--Dave

Re: [Plib-devel] PLIB 'Neat stuff' library

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

Dave McClurg wrote:
> 
> > Yes - although changing the present structure is a pain because CVS won't
> > let you delete directories.
> >
> 
> *pain* is the right word. i feel like we must be missing something.
> do other projects just *live* with this problem as well?
> or can we just email somebody at sourceforge and get him to take care of it

It's a *WELL* known problem it seems.

All sourceforge offer as help is:

1) Use the -P (IIRC) option to not create directories on your local
   machine if they are empty - hence you don't have to see the redundant
   directories.

2) Periodically wipe out the entire CVS directory and recreate it.
   This erases all the dead directories - but also wipes out all your
   accumulated revision history.

> ok. so we add 'tools' and 'auxlibs'.
> 
> auxlibs/ssg_sky
> auxlibs/ssg_particles
> tools/ssg_viewer
> etc...
> 
> just don't let me add the folder in windoze. :) lol

Yep.  I've just committed those  :-)

Do you actually have specific tools and auxlibs that you want
to commit?   If so, I'd better create the directories for
those too.
 
> > Examples and tools/applications that are not going to be needed
> > by 'Joe Public'
> > should be distributed separately to keep the file size to a
> > minimum though. Only
> > developers ever need those things - and developers are
> > increasingly becoming a
> > minority as PLIB gets more popular.
> >
> 
> really? the plib-users mailing list doesn't get much traffic

There are more users - and about the same number of developers - so
the proportion of users to developers is certainly increasing.

The lack of traffic on plib-users could just mean that people aren't
having many problems with it...but I suspect the reality is that
application developers are mistakenly using the PLIB-devel list - when
that's really intended for developers *OF* PLIB rather than developers
*USING* PLIB.

Application developers should really be considered *users* of PLIB
and hence post to plib-users.

Anyway - all the traffic is low (except for the odd mailbombing :-)
so I don't really care.

-- 
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] PLIB 'Neat stuff' library

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

Steve Baker wrote:
> 
> Joel Utting wrote:
> >
> > "Vallevand, Mark K" wrote:
> > >
> > > Steve, are you planning on collecting some neat stuff into PLIB?  An
> > > auxiliary library of stuff.  I have a few small, useful classes that
> > > someone else might find handy.  The auxiliary library would be a good
> > > places to put collections of textures, wav files, mod files and models.
> >
> > When you get back, Steve,
> 
> I'm back.  I have 1900 emails in my home account - and I'm scared to
> look into my work account!  SigGraph was *exhausting* - I may sleep
> for a couple of days.

Ha ! I thought my email was bad...

> *LOTS* of great new ideas to try though.  I want to get into texture
> synthesis from image samples and stuff...I may also have a new game
> project to start - I'm VERY excited about that because it's going to
> solve the artwork problem...but it's not firmly agreed yet and I can't
> say more.

Sounds interesting...but I can't comment more...

> 
> > I wonder about something like this for the
> > more complex primtives for PPE - sphere/cylinder that sort of thing. I
> > think that they might be better in an auxillary library to ssg, which
> > builds onto the features of ssg.
> >
> > Just a suggestion to save all this continual adding to ssg simply for
> > PPE.
> 
> Yes.  I agree 100%.  PPE (NIV100) features to support higher level
> primitives so that we can edit POV, VRML, etc without destroying those
> primitives will be very important - but the classes that we need to
> derive in order to do that won't be useful to the usual audience of
> SSG users - so an Aux library for SSG is important.

Great !

> One nasty issue that raises is how you'd load (say) VRML files
> without linking in the Aux library if your game didn't WANT to
> see spheres and cubes and things as anything other than
> a bunch of tristrips...Hmmmmm.

This wouldn't be a problem, would it - if its your game you'd simply use
PPE to convert those primitives to tristrips before putting the models
into the game. The only thing is if a game wanted to load random models
from the users hard disk - but surely you'd only do this in some kind of
editor anyway (?) not in an actual finished game. In either case if you
wanted to use the more advanced features of VRML and SSG you could
include the aux library anyway.

Bye - Joel.

RE: [Plib-devel] PLIB 'Neat stuff' library

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

> Yes - although changing the present structure is a pain because CVS won't
> let you delete directories.
>

*pain* is the right word. i feel like we must be missing something.
do other projects just *live* with this problem as well?
or can we just email somebody at sourceforge and get him to take care of it

> Hence we are somewhat stuck with 'src' for the PLIB sources and 
> 'examples' and
> 'doc' for the examples and documentation.  I don't have a problem with
> adding 'apps' and 'auxlibs' for the applications and auxiliary libraries.
> 
> Perhaps 'tools' would be better than 'apps' if we are talking 
> about viewers,
> players, convertors and such like.
>

ok. so we add 'tools' and 'auxlibs'.

auxlibs/ssg_sky
auxlibs/ssg_particles
tools/ssg_viewer
etc...

just don't let me add the folder in windoze. :) lol

> When we come to make a release though - I'd like to bundle the 
> aux libraries
> in with the main PLIB libraries so that people who just want to 
> install PLIB
> in order to get a game running don't have to download and install a dozen
> separate components.
> 
> Minimising dependencies is VERY important.
>

makes sense.

> Examples and tools/applications that are not going to be needed 
> by 'Joe Public'
> should be distributed separately to keep the file size to a 
> minimum though. Only
> developers ever need those things - and developers are 
> increasingly becoming a
> minority as PLIB gets more popular.
>

really? the plib-users mailing list doesn't get much traffic

--Dave

[Plib-devel] License change.

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

Dave has been in touch with the Free Software Foundation asking their advice
about the status of LGPL licensing for end-user products like games consoles,
cell-phones, etc.

As a result of those discussions, I intend to amend the PLIB licensing
arrangements by adding to the LGPL as follows:

   "This package is free software; you can redistribute it and/or modify it 
    under the terms of the GNU Lesser General Public License as published by 
    the Free Software Foundation; either version 2 of the License, or (at 
    your option) any later version. 

    This program is distributed in the hope that it will be useful, but 
    WITHOUT ANY WARRANTY; without even the implied warranty of 
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU 
    General Public License for more details. 

    You should have received a copy of the GNU Lesser General Public License 
    along with this program; if not, write to the Free Software Foundation, 
    Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 

|   As a special exception Steve Baker gives permission to link these
|   libraries with proprietary software and distribute the resulting
|   executable without including that proprietary code in any distribution
|   as the LGPL would normally dictate.
|
|   This exception is ONLY granted in the case of an embedded system in
|   which there is no possibility of an end user re-linking or recompiling
|   against new versions of this library that may appear in the future."

If anyone who has contributed to PLIB wishes to object to this license change,
please state that objection (and list the approximate sections of code that
apply) within 30 days and I will rewrite those sections as necessary so that
this change may be made cleanly.  Failure to respond within 30 days will be
taken as an agreement to transfer copyright ownership of your changes to
myself so that I may make the license change.

If anyone wants to suggest changes to the detailed wording, please do so within
7 days.

Notice that this explicitly DOES NOT permit console developers to change PLIB
without releasing those changes back into the public domain - however it does allow
them to implement a proprietary (closed source) interface layer between PLIB
and the target libraries (that are typically under NDA).  In that way, no NDA'd
information needs to be published and we can all be kept happy.

For developers of applications on 'normal' computers, this represents no
change to the normal LGPL restrictions.

IMHO, nobody should reasonably object to this change since the new definition
states that the modification of the license only applies to systems where it
makes no sense to retain the LGPL provision to allow end-users to relink
against new PLIB versions.

You can't re-link programs on a games console - so it makes no sense to require
application developers to abide by that rule.

However we *do* still get the benefits of any enhancements and bug fixes
to PLIB - which IMHO is the main reason for using LGPL in the first place.

What we gain from this change is that more people will use PLIB and hence
we'll get more creative input - and that's a straight win.

-- 
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] PLIB 'Neat stuff' library

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

Dave McClurg wrote:

> i kind of like how SDL manages games, apps, demos, and libraries that have
> been created around their *core* library.  they have each in a seperate
> download. this keeps the *core* plib very low level and clean.
> 
> http://www.libsdl.org/libraries.html
> http://www.libsdl.org/demos.html
> http://www.libsdl.org/apps.html
> http://www.libsdl.org/games.html

Well - yes - but I find SDL to be one of the WORST libraries to keep
track of.  I'm forever trying to build applications that demand
SDLmixer version x.y.z and SDL version p.q.r - I just can't keep track
of all the minor revision numbers of all the stoopid little components - some
of which in turn only work with some specific version of the base package.

There have been MANY SDL-based packages that I just can't keep running
together because they all demand mutually exclusive versions of one
sub-library or another.  SDL is a nice enough package - but the way it's
distributed SUCKS - IMHO.

I just wish they'd release ONE bundle with everything self-consistantly
up to date - even if that means that SDLMixer 1.2.3 is actually identical
to 1.3.0.

The thing that I like about our present approach with PLIB is that all
the component libraries are released together - you install it and you
have everything you need at that same revision.

> right now, http://plib.sourceforge.net has a few links to the more
> prominent projects that use plib.  it would be interesting and useful
> to see more in a format like http://www.libsdl.org/games.html.  i
> would certainly be interested in adding my own project there.

Hmmm - cute.

If you'd like to me to add something you are working on - I'd be very
happy to do so.  I'd like a small logo/icon to use with it also.

We should certainly think about doing something like the SDL list though.
 
> as for directory structure in cvs, i think the following might work:

> plib - core library
> apps/ssg_viewer
> apps/ssg_converter
> apps/mod_player
> demos/tux_example
> demos/fnt_example
> libs/ssg_sky
> libs/keyflier
> libs/particle_engine

Yes - although changing the present structure is a pain because CVS won't
let you delete directories.

Hence we are somewhat stuck with 'src' for the PLIB sources and 'examples' and
'doc' for the examples and documentation.  I don't have a problem with
adding 'apps' and 'auxlibs' for the applications and auxiliary libraries.

Perhaps 'tools' would be better than 'apps' if we are talking about viewers,
players, convertors and such like.

When we come to make a release though - I'd like to bundle the aux libraries
in with the main PLIB libraries so that people who just want to install PLIB
in order to get a game running don't have to download and install a dozen
separate components.

Minimising dependencies is VERY important.

Examples and tools/applications that are not going to be needed by 'Joe Public'
should be distributed separately to keep the file size to a minimum though. Only
developers ever need those things - and developers are increasingly becoming a
minority as PLIB gets more popular.

> other, *large* projects like ppe and tux_kart, of course, would have
> their own cvs source repositories like now.

CERTAINLY!

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

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

Wolfram Kuss wrote:
> 
> Steve wrote:
> 
> >Wolfram Kuss wrote:
> >>
> >> I just compiled all the projects from the workspace that is supplied
> >> with plib. I had no problems with pui or sl. The sl-project does NOT
> >> contain slHack.cxx. However, no os-project is included.
> >
> >So what do you guys want me to do (if anything) ?
> 
> slHack.cxx exists, but isnt in the makefile. Is it used at all?

No - it shouldn't be in the distro or CVS - I put it in by accident.

I've just removed it from CVS.

> There is a directoy os and one util? plib.sourceforge.net
> seems to say os is ul which we know is the directoy util.
> BTW, the link is broken.
> 
> As I said, everythink compiled fine for me. So, the only problem MIGHT
> be that things (that are not needed for PPE) are missing.
> 
> BTW, are you still on Siggraoh?

No - I got back late last night (plane delayed 3 HOURS!) - I've just
finished ploughing through all those emails.

SigGraph is VERY exhausting - but AMAZINGLY good.  If you have any
interest in graphics at all, you should get your company to send you
to SigGraph.  It's impossible to go away without a million good ideas
buzzing around in your head.

I need to write a post explaining what I've been doing to PPE (LOTS!)
but I'll start a new thread for that.

-- 
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] PUI questions

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

Steve wrote:
> > 
> > I'm just starting to use PUI and I've looked at complex.cxx.
> > http://plib.sourceforge.net/pui/index.html doesn't seem to work.
> 
> That's odd - it used to.
> 
it works now. must have been my connection.

> > Is there any project that makes heavy use of PUI?
> 
> Some things I've done at work have - but I have nothing significant
> that I could release.
> 
ok. just checking. i'd like to make a few pui demos anyway.

--Dave McClurg

Re: [Plib-devel] PUI questions

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

Dave McClurg wrote:
> 
> I'm just starting to use PUI and I've looked at complex.cxx.
> http://plib.sourceforge.net/pui/index.html doesn't seem to work.

That's odd - it used to.

> Is there any project that makes heavy use of PUI?

Some things I've done at work have - but I have nothing significant
that I could release.

> rendering callbacks, sliders with list boxes, multiple interfaces
> that are linked together, python driven pui scripting

No.
 
> I want to start by making a file requestor (slider + listbox)
> i didn't see a listbox widget.  would i use a "frame"?

I guess so.
 
> btw, did pli...@li... ever recover?
> i had to un-subscribe because of all those auto-responder messages

Yes - it's all better now.  An email to the guy's employer didn't
seem to have worked - but he's no longer subscribed to the list
so I guess someone asked Sourceforge to can 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

RE: [Plib-devel] PLIB 'Neat stuff' library

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

> > Steve, are you planning on collecting some neat stuff into PLIB?  An
> > auxiliary library of stuff.  I have a few small, useful classes that
> > someone else might find handy.
> 
> Yes.  I certainly plan to do that...and quite soon too.
> 
<snip>

> I haven't quite decided on the directory layout yet.  Should there
> be an 'aux' library for each PLIB component (Like 'libGLU': SSGU, PUIU,
> SLU, etc) or one gigantic utility library (PLIBU)?  Should each little
> suite of stuff be in a separate lib (SSG_sky, SSG_fractals, etc) ?
> Should there be one directory for all utilities or a separate directory
> under each of the existing library levels?  Do we want to distribute
> all that stuff along with PLIB or as a separate download?
>

i kind of like how SDL manages games, apps, demos, and libraries that have
been created around their *core* library.  they have each in a seperate
download. this keeps the *core* plib very low level and clean.

http://www.libsdl.org/libraries.html
http://www.libsdl.org/demos.html
http://www.libsdl.org/apps.html
http://www.libsdl.org/games.html

right now, http://plib.sourceforge.net has a few links to the more
prominent projects that use plib.  it would be interesting and useful
to see more in a format like http://www.libsdl.org/games.html.  i
would certainly be interested in adding my own project there.

as for directory structure in cvs, i think the following might work:

plib - core library
apps/ssg_viewer
apps/ssg_converter
apps/mod_player
demos/tux_example
demos/fnt_example
libs/ssg_sky
libs/keyflier
libs/particle_engine

other, *large* projects like ppe and tux_kart, of course, would have
their own cvs source repositories like now.

--
Dave McClurg

Re: [Plib-devel] PLIB 'Neat stuff' library

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

> Dave McClurg wrote:

> Is the KeyFlier something that could be moved out of ssg into the
> auxillary library?

YES!!!!

-- 
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] PLIB 'Neat stuff' library

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

Joel Utting wrote:
> 
> "Vallevand, Mark K" wrote:
> >
> > Steve, are you planning on collecting some neat stuff into PLIB?  An
> > auxiliary library of stuff.  I have a few small, useful classes that
> > someone else might find handy.  The auxiliary library would be a good
> > places to put collections of textures, wav files, mod files and models.
> 
> When you get back, Steve,

I'm back.  I have 1900 emails in my home account - and I'm scared to
look into my work account!  SigGraph was *exhausting* - I may sleep
for a couple of days.

*LOTS* of great new ideas to try though.  I want to get into texture
synthesis from image samples and stuff...I may also have a new game
project to start - I'm VERY excited about that because it's going to
solve the artwork problem...but it's not firmly agreed yet and I can't
say more.

> I wonder about something like this for the
> more complex primtives for PPE - sphere/cylinder that sort of thing. I
> think that they might be better in an auxillary library to ssg, which
> builds onto the features of ssg.
> 
> Just a suggestion to save all this continual adding to ssg simply for
> PPE.

Yes.  I agree 100%.  PPE (NIV100) features to support higher level
primitives so that we can edit POV, VRML, etc without destroying those
primitives will be very important - but the classes that we need to
derive in order to do that won't be useful to the usual audience of
SSG users - so an Aux library for SSG is important.

One nasty issue that raises is how you'd load (say) VRML files
without linking in the Aux library if your game didn't WANT to
see spheres and cubes and things as anything other than
a bunch of tristrips...Hmmmmm.

-- 
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] PLIB 'Neat stuff' library

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

"Vallevand, Mark K" wrote:
> 
> Steve, are you planning on collecting some neat stuff into PLIB?  An
> auxiliary library of stuff.  I have a few small, useful classes that
> someone else might find handy.

Yes.  I certainly plan to do that...and quite soon too.

Curt's 'instant sky model' code is an excellent example (with a couple
of function calls, you get a properly updating sky with clouds, stars,
sun, moon, planets, etc - with a little more effort, you get correct
time-of-day rendering - and it even reproduces eclipses and such
automatically).

I haven't quite decided on the directory layout yet.  Should there
be an 'aux' library for each PLIB component (Like 'libGLU': SSGU, PUIU,
SLU, etc) or one gigantic utility library (PLIBU)?  Should each little
suite of stuff be in a separate lib (SSG_sky, SSG_fractals, etc) ?
Should there be one directory for all utilities or a separate directory
under each of the existing library levels?  Do we want to distribute
all that stuff along with PLIB or as a separate download?

>  The auxiliary library would be a good
> places to put collections of textures, wav files, mod files and models.

Hmmm - I think that 'Artwork' belongs somewhere else.  I'm greatly
enthusiastic about such collections since good freeware artwork is hard
to find - but I just don't think it belongs with PLIB since other packages
like CrystalSpace can also make use of it.

Software that creates textures, etc would be appropriate though - if
you wrote (say) an ssgTexture derived class that made fractal textures
or Perlin noise or something - then that would be a useful thing to add.

There are lots of existing repositories of free and semi-free art out
there.  Check out (for example) 3DCafe.  Perhaps contributing this stuff
there makes more sense.

It's awfully tempting to make "yet another texture repository" though.
If you want to do this, getting another sourceforge account to dump it
all into would be very easy...and I'd certainly want to link to it from
the PLIB site.

Too many of the existing repositories have no information about the
license under which these objects are distributed.  We need a place
where it's clearly stated that ALL content is under (say) the Xfree
license or something.

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

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

Steve wrote:

>Wolfram Kuss wrote:
>> 
>> I just compiled all the projects from the workspace that is supplied
>> with plib. I had no problems with pui or sl. The sl-project does NOT
>> contain slHack.cxx. However, no os-project is included.
>
>So what do you guys want me to do (if anything) ?

slHack.cxx exists, but isnt in the makefile. Is it used at all?

There is a directoy os and one util? plib.sourceforge.net
seems to say os is ul which we know is the directoy util.
BTW, the link is broken.

As I said, everythink compiled fine for me. So, the only problem MIGHT
be that things (that are not needed for PPE) are missing.

BTW, are you still on Siggraoh?

Bye bye,
Wolfram.

Re: [Plib-devel] anyone have plib for windows?

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

Arthur Yarwood wrote:
> 
> Does anyone have plib pre-compiled for windowz? Or maybe some makefiles for
> the free Borland compiler. I want to try and port my GL apps to windowz you
> see, but without plib under windows I'm kinda stuck.

I'm not a windoze person - but I know that people who use the CygWin compilers
have a much easier time of things.  If you get a copy of CygWin (I believe it's
free) then you can use the existing PLIB Makefiles' without change.

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

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

Wolfram Kuss wrote:
> 
> I just compiled all the projects from the workspace that is supplied
> with plib. I had no problems with pui or sl. The sl-project does NOT
> contain slHack.cxx. However, no os-project is included.

So what do you guys want me to do (if anything) ?


-- 
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] PUI questions

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

Dave asked:

>btw, did pli...@li... ever recover?
>i had to un-subscribe because of all those auto-responder messages

Yes, the postings have stoped, you (and everyone else) can
re-subscribe.

Bye bye,
Wolfram.

[Plib-devel] PUI questions

[Dave M. <da...@po...>]

I'm just starting to use PUI and I've looked at complex.cxx.
http://plib.sourceforge.net/pui/index.html doesn't seem to work.

Is there any project that makes heavy use of PUI?
rendering callbacks, sliders with list boxes, multiple interfaces
that are linked together, python driven pui scripting

I want to start by making a file requestor (slider + listbox)
i didn't see a listbox widget.  would i use a "frame"?

btw, did pli...@li... ever recover?
i had to un-subscribe because of all those auto-responder messages

-- 
Dave McClurg
dav...@dy...     http://www.dynamix.com
da...@po... (home)        http://www.pond.net/~davem