plib-devel

[Plib-devel] Utility - ulNet class

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

Hello

This is just a hack of steves code for the networking code, just renamed
with a minor change in recvMessage. This was compiled with cygwin. The only
problem I had was in the recvMessage, the problem is that steves code had:
int r = recvfrom ( sockfd, mesg, length, 0, (sockaddr *) in_addr, (unsigned
int *)(&len) );
but the unsigned int is suppost to be int in cygwin.

Thanks Ben
ps Attached is the code. Could someone tell me the best location for sending
updates.
 <<ulNet.zip>> 

Documentation - doxygen (was Re: [Plib-devel] Work outstanding.)

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

Hi,

> I'd *really* like to help with this.  Documentation is a pretty vital part
> of getting newbies running, so I'll see what I can do in this regard.  I'm
> thinking of HTML page per class, with member variables and methods
> documented.

Yes, the advantages of having the functions (and variables) documented in the source code can't be under estimated.  I was first
introduced to this when programing on the Amiga (all the public OS functions were documented in this way).  It's _very_ useful.

It means that if someone adds a function they can document before the cvs commit, and the documentation automatically gets updated.
And you won't believe the number of bugs you catch when you start documenting  functions individually :)

> Ideally, a code fragment also, but that relies on having a lot
> of little code fragments!
>
> The Java guys use a neat system called Javadoc, which allows comments
> embedded in code to be cross-compiled into documentation.  You need to use
> some special tags in the comments for the parser to find, but it works
> really nicely if people do it as they go.  Assuming that the comments are
> up to date, a documentation update is as simple as running the Javadoc
> parser through the source.  http://java.sun.com/products/jdk/javadoc/ if
> you're interested.

This is from the Javadoc FAQ:

----
A10.   Can I run javadoc on source files from other languages, such as C, C++ or VisualBasic?

No. Javadoc runs only on Java source code. See the previous question for the explanation. However, other vendors have worked on such
documentation tools. They are listed at the bottom of this page.
----

> There are a number of packages which do the same thing for C++, and I was
> going to have a look at Doxygen, which seems to be quite popular -
> http://www.stack.nl/~dimitri/doxygen/  I'll post some findings about this;
> the last thing I want is to suggest other developers use some weird
> commenting system which most people will just ignore.  It has to be easy
> enough to use that it's almost no effort.

I've used doxygen for my current project and it's very easy to use - I was going to suggest it for plib before this post.  It's
along the lines of:

/**
 * Brief class Description
 * @author Me!
 * @bug Doesn't work - at all!
 * Long class description - HTML tags are <B>allowed</B>
 */
class MyClass {
    public:
        int score; // Current score

        // I know Steve hates the // comments - you can also do this:

        /**
         * Current damage
         */
        int damage;

        /**
         * Brief function description
         * @param x x offset - must be >0
         * @param y y offset - must be > 0
         * @return a new y position
         * Long description here
         * @see AnotherFunction()
         */
        int GenNewY ( int x, int y ) ;
};

Etc.. It actually understands a fair amount of comment formats, so you don't have to use the styles above (although I would suggest
we pick a style and stick to it).

The documentation (for functions), be with the prototype or the declaration.

It will generate it's documentation in HTML, man page format, RTF, and LaTeX.  It will even convert embedded HTML tags into the man,
LaTeX and RTF formats.  It will embed PDF-style links into the LaTeX file so it can be converted to a PDF with hyperlinks intact.

It also automatically generates inheritence diagrams, and also (in the later versions) collaboration diagrams!

If you use doxysearch on the site you can site the documentation online.  This is quite useful as you can search for bug or todo and
get a list of functions back.

IMHO doxygen is fantastic, and I wouldn't hestitate to recommend it.  You can look at the generated documentation for my project
(spacething) at:

http://www.spacething.org/development/docs/

An example of the graphical inheritence diagrams is at:

http://www.spacething.org/development/docs/inherits.html  (scroll down the page a bit)

and an example collaboration diagram:

http://www.spacething.org/development/docs/class_enobject.html

It's a bit of a mess (code and structure wise), but you should be able to see what doxygen is capable of.  On my site it's set up so
that the documentation is automatically regenerated whenever a cvs commit is completed (well actually twenty minutes afterwards).  A
similar autogeneration can be set up on sourceforge (apparently - I haven't tried it yet, but they tell me it's possible).

I've never had any trouble _what__so_ever_ when using the development versions of doxygen - the author has a very high standard.
Since the development release has many more features than the stable, if you choose to use doxygen I'd go with that one.

> Comments?

I really would like to suggest doxygen. :)

Sam

Re: [Plib-devel] Work outstanding.

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

Gil wrote:

>>Why not use PPE? [...]
>
>Well, the attraction with perfly is that it really doesn't do anything 
>apart from load and display models.  [...] Hopefully, puFly will have 
>enough in it that people can use it as a basis for their own first 
>tinkerings 

Ok. But I still think it should take as much from PPE as possible.
For example, I think the viewing can be used 100%.
With other features, we could modularize the stuff that puTrace or
puView or however you would call it into seperate files so that there
is no duplication of effort.

>I hadn't thought of puTrace being used inside PPE.  Given that PPE is a 
>modelling package not a gaming engine, is this something you would really 
>need to do?  Obviously it's possible, but I'm not really clear on what you 
>would use it for; I'm open to comments on this.

So am I ;-), I unfortunately never had the opportunity to use
something like perFly. But I asumed that it is something for the
developer or artist, not the end user? Probably it would be best to
have the performance monitor both in the engine and the modeler.
In the engine for the developer, so that he can see the performance
where it matters, with sound and ai etc going on.
In the modeler, the developer can quickly make changes, for example
that car model is too slow - lets try it with opaque windows.


>I'm a big fan of nice docs, 

So am I.

>and I'm more than happy to put the effort into them 
>provided other people can point out my errors :-)

Ok, thats no problem :-).

>Gil

Bye bye,
Wolfram.

Re: [Plib-devel] Work outstanding.

[Gil C. <g.c...@ca...>]

At 09:25 AM 8/10/00 +0100, you wrote:
>Gil wrote:
>
> >puTrace
>
>Sounds great! Obviously, the more info on bottlenecks there is, the
>better. For example, it would be GREAT to know how much
>texture-swapping there is going on, but I doubt this can be done
>portably?

Over to Steve for this one, but I suspect that with a little user 
assistance (eg. "How much texture memory does your board have"), we can 
probably have a stab at guessing how much texture swapping from main memory 
to texture memory is occurring.

Anybody know if you can monitor AGP transactions to pick this kind of thing 
up?


>I think the first step should be simply to measure all the things.
>Displaying and(or sending them via TCP/IP is of secondary importance.

Agreed.


> >puFly
>
>Why not use PPE? It has several windows, a hierarchial view, great
>viewing via mouse or keyboard or commands (for example, "view
>everything"). It allows you to edit the model while seeing the
>performance. Of course PPE can load all plib stuff, since it is build
>on plib.

Well, the attraction with perfly is that it really doesn't do anything 
apart from load and display models.  Perfly's ability to change the 
rendering parameters is very nice, and keeping it as a simple but powerful 
program means that the source stays compact - compact enough to go with the 
standard examples tarball for PLIB.

The real win with this is that people can build puFly and load up models 
very easily.  The code will be compact enough that people can see how to 
not only use the loaders, but also exercise all of the rendering 
methods.  Hopefully, puFly will have enough in it that people can use it as 
a basis for their own first tinkerings - I know I'm still using the 
original tux-on-a-box program as my starting point for experiments!

>We could create a new window for puTrace output.

I hadn't thought of puTrace being used inside PPE.  Given that PPE is a 
modelling package not a gaming engine, is this something you would really 
need to do?  Obviously it's possible, but I'm not really clear on what you 
would use it for; I'm open to comments on this.

 >[autmatical docs]

>I am not against them. But I think we need a handcrafted doc for the
>users of plib as well. For example, you have to give an overview of
>plib.This fits nowhere in the code.

Very true.  I guess you can draw the distinction between a programmer's 
guide and an API reference - the API reference is automagically updated 
from source comments, while the programmer's guide is a more static 
document which gets updated when major new features get added.  I'm a big 
fan of nice docs, and I'm more than happy to put the effort into them 
provided other people can point out my errors :-)

Gil

Re: [Plib-devel] Work outstanding.

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

Gil wrote:

>puTrace

Sounds great! Obviously, the more info on bottlenecks there is, the
better. For example, it would be GREAT to know how much
texture-swapping there is going on, but I doubt this can be done 
portably? 

I think the first step should be simply to measure all the things.
Displaying and(or sending them via TCP/IP is of secondary importance.

>puFly

Why not use PPE? It has several windows, a hierarchial view, great
viewing via mouse or keyboard or commands (for example, "view
everything"). It allows you to edit the model while seeing the
performance. Of course PPE can load all plib stuff, since it is build
on plib. We could create a new window for puTrace output.

>I'd *really* like to help with this.  Documentation is a pretty vital part 
>of getting newbies running, 

Yes.

>[autmatical docs]

I am not against them. But I think we need a handcrafted doc for the
users of plib as well. For example, you have to give an overview of
plib.This fits nowhere in the code.

>Gil

Bye bye,
Wolfram.

Re: [Plib-devel] Re: KobayashiMaru & plib

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

Steve wrote:

>Finally, sort your vertices in a vertex array so that the first one in the array
>is the most important, and the last is least significant.  

Yes. A friend of mine wrote a program using software-rendering a long
time ago that also sorted the polys according to importance. Each
frame, when the "time slice", for example 1/50 of a second, was up, it
simply stopped rendering. This is not like LOD, since the unimportant
polys were simply missing, there were holes. Still, it looked very
good, even if half of the polys were thrown away.
He did this only when the scene or the camera changed, and rendered
the complete models once everything was static. The program was
similar to PPE and he could draw the 3D-cursor without rendering the
rest (when drawing the 3d-cursor, he saved the pixels underneath).
Anyway, I guess THIS method (not LODs though) is slightly outdated.


>THere have been long threads on the LGDG (Linux Games Developer Group) about
>the lack of motivated artists who'll work for nothing.  

This could lead to a thread about which professionals might work for
nothing :-). I am not sure there are many besides programmers.

>Response from the
>artists strongly suggests that what few of them WILL help are not likely to
>jump into just any project - they are going to look for projects with experienced
>programmers with a proven track-record.

Of course. Artists can choose their project and they want to
participate in successful projects, so they will choose.

>If you are *REALLY*
>lucky, you may find an artist who will be interested in designing things like 
>spaceships or big-breasted aliens women with three heads and forked tongues...but
>they are unlikely to be interested in doing these kinds of silly little jobs.

Yes. Yesterday I was at an ex-artists (we call them technical
draftsman) of ours who now works free-lance (sometimes for us). He is
prepared to work on a free project if he has time. But "only" to learn
new stuff that will advance him and that the industry needs. The
biggest need in the game and film industries seems to be characters
(humans, monsters, animals etc), so if he would do sthg it would be
characters.
BTW, I was there to look at things in 3D Studio that we might use in
PPE, more on the PPE list.


>Let me tell you about Tux-A-Quest-for-Herring.
>
>It was the first *ever* 3D game for Linux.  

Yes - a very interesting thing. I would probably have contributed if I
had heard about it beforehand, but I was not in the linux community.

>I got:
>
>  150,000 people visiting the web site over the first 12 hours.
>   15,000 people downloaded it in the first 12 hours.
>    1,500 emails complaining/complimenting/thanking me for TuxAQFH
>          within the next week or so.
>   ...one year later...
>      150 people are subscribed to the Tux mailing lists.
>       15 people have *ever* offered to help with artwork/music/models.
>      1.5 (OK...2 actually) other people have actually contributed
>          *anything* to Tux *ever*. One piece of unusable music - and a
>          couple of unusable models.  No significant chunks of code at all.
>    *NONE* of those things has ever been useful enough to distribute with
>          the game.

Wow, that's even worse than I thought :-(. It seems many want to start
a new project (see all the modelers on Sourceforge) and few want to
contribute to the project of other people :-(.

>Remember - it took 100 people working full-time 5 years to create
>Mario'64.  You have about three times that amount of work.  You should
>be finished in about 1500 years.

Well, out of the 100 people there are many managers, advertisement
people, manual writers etc. 
But of course it is not possible to compete with the commercial games
writers except MAYBE under the best conditions (many knowledgable
contributors with much time and motivation that work together well)
or of course by programming simple games that work because of the
idea, a la Tetris.


Bye bye,
Wolfram.

RE: [Plib-devel] PLIB developers needed.

[Paul B. <pbl...@di...>]

>From: Dave McClurg [mailto:Dav...@dy...]
>Subject: RE: [Plib-devel] PLIB developers needed.
>
> for private functions, use all_lower_case unless they would 
> pollute the name space in which case you should use _xxMixedCase
> (note the leading underscore).  if a variable pollutes the name 
> space, use _xxMixedCase. 

Note that this technically goes against the portability aspect
of PLIB as identifiers in the global and std:: namespaces starting 
with '_' and '__' are reserved for the implementation in ANSI C++.

http://oakroadsystems.com/tech/cppredef.htm#Groups

I know it is used by alot of code and I do it too, but I thought
it should at least be known.  I get killed by it everytime I
write a header file:

#ifndef __Foo_h__
#define __Foo_h__
#endif

is discouraged (because the two leading underscores) as the
implementation (compiler) may legally predefine those values.

Paul

Re: [Plib-devel] PLIB developers needed.

[Gil C. <g.c...@ca...>]

>Linux people: Please don't do this:
>
>     for ( int i = 0 ; i < 10 ; i++ ) whatever ;
>     for ( int i = 0 ; i < 20 ; i++ ) whatever ;
>
>(Although it's perfectly legal C++ - MSVC barfs on it - I forget
>  about this *every* time - sorry Windoze dudes!)

But to credit Leath Muller (I think), this will fix that problem:

     { for ( int i = 0 ; i < 10 ; i++ ) whatever ; }
     { for ( int i = 0 ; i < 20 ; i++ ) whatever ; }

But it's daggy and isn't something you'd write given a choice :-)

Gil

Re: [Plib-devel] Work outstanding.

[Gil C. <g.c...@ca...>]

>   * Dave has shelved his Blender-VRML loader for a while and asks for 
> help with
>     continued development.  If this 'Blender-VRML' subset is the best 
> interchange
>     format between Blender and PLIB then we'd better write an exporter 
> too so that
>     Blender and PrettyPoly can exchange files too.

That sounds like me...  I'll have a look at where Dave's up to with this 
loader tonight.  I assume it's somewhere in the CVS repository?

I might as well throw a couple of my future ideas into the ring before they 
even make it to the design stage (true vapourware!) to see if they're of 
interest to others.  (These ideas come _after_ the VRML loader, I promise!)

puTrace
~~~~~~~

Basically a benchmarking and information library which developers can link 
against during development for timing and rendering stats.  I'm influenced 
by Performer's perfly program here, so the kinds of things I'm thinking of are:

* app/cull/draw times
* frames per second - peak and averaged
* number of tris in view frustum
* tri strip lengths
* textures loaded
* state information
* toggle rendering between different modes - flat, shaded, wireframe etc
* lighting on/off
* lots of other things too!

puTrace would be a library in addition to the main PLIB core, and would 
look after measurement and display of all of these parameters.  Using the 
right #if directives, the trace can be left in the source, but compiled out 
for release versions of software.

As a possible extension, the display of puTrace information might be 
available on a networked machine - in other words, the main app links in 
puTrace to do the measurements, and the results are sent over a TCP/IP 
connection to another machine which then displays them.

The secondary display application will also be a PLIB app, set up to 
receive and display the stats.  This way, the main machine's rendering is 
"untouched" by puTrace, and the second machine can do much more in terms of 
logging results without affecting the main app under test.  Since puTrace 
will already have the HUD code built into it for local hosting of debug 
info, writing a remote version is almost a no-brainer.

puFly
~~~~~

*Very* similar to perfly - IOW, a program which can load and display any 
type of PLIB compatible model, but allows interactive display of rendering 
stats and a graphical display of the scene graph.  Obviously, this package 
will link puTrace in, and make heavy use of it.  In fact, my plan for 
testing puTrace is to write puFly anyhow, so it's almost going to fall out 
as by-product.  (Gee, is the phonetic pronounciation for puFly "POO-fly"?)

puFly would be a possible replacement for the current "tux on a box with 
panning camera" demo, and would allow a showcase of the features of PLIB. 
Hopefully.

For a rough idea of what perfly can do, have a look at this page which I've 
quickly cobbled together.

http://www.powerup.com.au/~gcarter/plib/perfly.html

It shows a couple of screenshots from perfly running on my O2 and 
displaying a simple model.  Perfly also runs on the Linux distribution of 
Performer if you've got it installed.

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

I'd *really* like to help with this.  Documentation is a pretty vital part 
of getting newbies running, so I'll see what I can do in this regard.  I'm 
thinking of HTML page per class, with member variables and methods 
documented.  Ideally, a code fragment also, but that relies on having a lot 
of little code fragments!

The Java guys use a neat system called Javadoc, which allows comments 
embedded in code to be cross-compiled into documentation.  You need to use 
some special tags in the comments for the parser to find, but it works 
really nicely if people do it as they go.  Assuming that the comments are 
up to date, a documentation update is as simple as running the Javadoc 
parser through the source.  http://java.sun.com/products/jdk/javadoc/ if 
you're interested.

There are a number of packages which do the same thing for C++, and I was 
going to have a look at Doxygen, which seems to be quite popular - 
http://www.stack.nl/~dimitri/doxygen/  I'll post some findings about this; 
the last thing I want is to suggest other developers use some weird 
commenting system which most people will just ignore.  It has to be easy 
enough to use that it's almost no effort.

As some more general reference material, I'd also like to reference some 
other papers - mostly from SGI - about real time rendering issues.  Eric 
Haines' website at http://www.realtimerendering.com also has a treasure 
trove of good information.  These links plus other local docs would form 
some basic self help for people who land at the PLIB project without enough 
background in realtime 3D to be able to just jump in and start using PLIB.

Comments?

Gil

[Plib-devel] Work outstanding.

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

OK - so we have LOTS of enthusiastic new developers signed up to
lighten my load.

I just trawled back through the list of 'pending' things in my mail
queue.  If you have a yen to pick up one or more of these, please
mention it by email so we don't get duplicated work.


  * 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 without breaking TuxAQFH.

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

  * Curt Olson has a nifty 'sky' model class in 'SimGear' that is really
    just *begging* to go into an SSG Utilities library in a form that
    frees it of it's remaining FlightGear heritage.  Just about every
    program I write at home would benefit from that.

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

    Check out the email thread 'SGSky class'

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

  * 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

  * Dave Lawrence posted a 'frame rate limiter' routine
    that may be usefully added as a feature to ulClock. His
    original code isn't much use - but take the idea of noting the
    time at some point - then a bit later saying - sleep/spin
    until at least some number of milliseconds has elapsed.

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

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

  * Dave has been worrying about ssgSelector nodes with more than 32 children,
    and how to time ssgTimedSelector in *realtime* instead of frame-time.
    I maintain that you need both options - either as a flag inside ssgTimedSelector
    or as a derived class that does realtime timing.
    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.

  * There have been some comments about the need to delete PUI nodes during
    their own callback functions.  This turns out to be incredibly useful - but
    it's not legal C++ to delete a class object whilst inside a member function
    that belongs to that same object.  There is an idea for a fix for this but
    it's very tricky.  Read the thread:

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

  * Dave has shelved his Blender-VRML loader for a while and asks for help with
    continued development.  If this 'Blender-VRML' subset is the best interchange
    format between Blender and PLIB then we'd better write an exporter too so that
    Blender and PrettyPoly can exchange files too.

  * Leath Muller sent me 'lwload.cxx' and 'lwload.h' files which he says would make
    a good starting point for a 'LightWave' loader.  It would be nice to investigate
    that.  (If you want to attack this, let me know and I'll email you the files).

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

    (Notice that for *environment mapping* you may need more precise normals).

  * Multiple textures per polygon.

  * Enhance ssgState to allow for some of the more common/useful extensions
    to OpenGL.

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

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

Well, welcome to my hell!

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

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

Norman Vine wrote:

> I can keep the Cygwin stuff upto date for us
> 
> I am nhv at sourceforge
> ( check prettypoly developers if more info needed )

OK - you got it!


Let me thank everyone for their prompt response to my plea
for help - we now have seven people signed up with CVS access,
which is probably enough to spread the load of adding patches
and such like.

If anyone is planning a major contribution and would benefit from
write access - let me know.

-- 
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] KobayashiMaru 0.2.9 for BeOS

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

Alexander Rawass wrote:

> KobayashiMaru 0.2.9 has now been compiled for Beos5
> and is available from my Homepage.
> 
> I had to patch plib-1.3.0 to compile plib - Beos
> doesn't seem to have a glXContext , so you just have to put some
> #ifndef BEOS
> in puInit and ssgInit,
> it simply works without this glXContext - check.

It won't work if your application opens two or more OpenGL windows
(like PPE for example).

There *must* be some kind of equivelent function to tell OpenGL
which
window to render into from now on.

Since you are probably the *only* BeOS user right now - it's down
to you to find out what and fix it!

Thanks!  It's good to hear of success under BeOS.

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

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

> Dave McClurg wrote:

> 2) don't use C++ exotics like STL, templates, exceptions, operator overloading, and iostreams to make porting easier.  if you love that kind of stuff, you can always wrap plib in your app code.

I'd add that classic:

Windoze people: Please don't do this:

    for ( int i = 0 ; i < 10 ; i++ ) whatever ;
    for (     i = 0 ; i < 20 ; i++ ) whatever ;

(It's illegal in modern C++ and although MSVC likes it, GNU C++ doesn't).

Linux people: Please don't do this:

    for ( int i = 0 ; i < 10 ; i++ ) whatever ;
    for ( int i = 0 ; i < 20 ; i++ ) whatever ;

(Although it's perfectly legal C++ - MSVC barfs on it - I forget
 about this *every* time - sorry Windoze dudes!)

Instead, everyone do this:

    int i ;
    for ( i = 0 ; i < 10 ; i++ ) whatever ;
    for ( i = 0 ; i < 20 ; i++ ) whatever ;

(Yuk!)

The 'P' in PLIB stands for "Portability" - and the rest is just a "LIBrary"!

...which reminds me...  :-)

 I tried to compile PLIB on an SGI machine at work - and your 'const-ification' of the clock
routine stopped it from compiling on the IRIX compiler.

You had:

  class ulClock
  {
    ...
    public:
      ...
      int getSomething () const { return something ; }
      ...
   } ;

The 'const' seemed to do *bad* things to the SGI compiler.

Could you remind me what exactly a 'const' right there actually *does*? 

...and then remove them anyway!

> 4) For any major change, please consider posting to this list *first*.  Other developers
> may have a more elegant method of implementing the same thing or already have a patch that
> they didn't think anyone else was interested in.  Perhaps the major change you are thinking
> about does not belong in PLIB at all and would be better off in an auxilliary library or example.

This is by far the most important thing.  I've had one or two really unfortunate cases
where someone has put in a LOT of effort into doing something that wasn't (IMHO) appropriate
for the future of PLIB - so I had to refuse to add them to the package.  In both cases, people
we ...erm...*polite* about it - but it made me feel *REALLY* uncomfortable to have to do 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] KobayashiMaru & plib

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

Alexander Rawass wrote:

> Yes, I am truly an Open Source Freak.
> 
> I would gladly have dumped KobayashiMaru if Parsec would have been
> the better one, to help extend Parsec to the thing I want, but
> this is only possible with open source.

Have you emailed and asked if your could join their team?

Some developers like to get things working nicely before they
release the source code.

I'm actually like that.  Neither TuxAQFH nor TuxKart were released
as OpenSource until they were actually working.

It's nice not to have outside interference and endless questions
about the code until it's more or less ready to go.

But I understand your point of view 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] Re: KobayashiMaru & plib

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

Alexander Rawass wrote:

> > Look in ssgVtxTable.cxx - find the 'draw_geometry' routine and add up the
> > number of vertices and polygons right there - into a global variable somewhere.
> 
> Maybe I'd need also something like
>   ssg_entity=createLevelOfDetailFromEntity(int nr_of_polygons, orig_entity)
> 
> meaning a routine that takes and entity and tries to reduce somehow the
> number of triangles in that entities, till there are (more or less) only
> nr_of_polygons left or so.
> There are some Modelers which have this feature, of course the results
> look like shit, but as part of plibssg I could break down high-detail
> models to low-detail, as long as I've got a shortage on models.

The *trendy* way to do this is to collapse triangles by moving one vertex
of the model to the one next to it - then removing all the zero area polygons
that result.

You decide which vertices to 'collapse' in this way as an offline process - choosing
which vertex of the model is least visually important - so you collapse that first,
then work gradually into the more and more 'important' vertices.

Finally, sort your vertices in a vertex array so that the first one in the array
is the most important, and the last is least significant.  You can do the same
thing with the 'index' array - so that polygons that are deleted first are at
the end of the array.

Choosing 'importance' is a 'black art' - but is do-able automatically - at least
to some degree.

It would be cool to derive a class from ssgVtxArray to do this...although the
automatic vertex-importance selection code would need to be an external program -
which begs the issue of what file format to use... ".SSG" I suppose - that's
extensible so you could extend it to do what you need for your new class.

*NOT* for beginners.

For the first step, figure out how big your model is - and work out at what
range it'll be (say) less than 3 pixels across - and switch it out into a
simple tetrahedron of an appropriate colour (4 triangles - one triangle-strip).
Figure out the range at which it'll be less than one pixel - and throw it away
altogether at that range.

Use an ssgRangeSelector node to do that - and you'll see an immediate improvement
(I suspect).

> > If you ARE using GLUT text, I can tell you for *SURE* that that's the major reason.

> Now I'm timing the Huds, now I see, and I have even a new Hud (Radio_Display)
> that displays lots of message, and the more messages, the slower.
> 
> As a novice, I wouldn't have thought of that - or at least, that it will
> draw so much. Sorry.

S'OK - that's why we are here to help!

> > > > However, for a fast action game, nobody will have time to read all that tiny
> > > > text anyway.  It's generally considered a good idea to use as little text
> > > > as possible in a game - preferably none at all.
> > >
> > > The text will even get more - the game is far from being 1.0.0 , and most
> > > output is more or less debugging ;-)
> >
> > Well, I think you should stop and think about that.
> 
> I'll use puFnt as soon as I can.

That'll help - but:

  a) puFnt text can be fuzzy at small scales.
  b) it's still two triangles per character - so 200 characters on-screen
     is 400 poorly-tristripped triangles.

I think you should consider VERY carefully how much text you need to display.
Can you only display ship stats when the thing is clicked on or something?

Can you freeze the action while they read "radio" messages - or scroll them
slowly across a small region of the screen so you can only see a handful of
characters at a time...that can actually look rather cool.

> > > Yes. But I am as bad in drawing images as for modeling.
> >
> >   :-)
> >
> > Write a program that does a 'glReadPixels' of the graphic you have now - save
> > it into a file that you can draw (as a texture) instead of the original.
> >
> > You really *will* need to use some minimal painting skills before you are
> > done with this game.
> 
> No, I simply need a lot of people with great painting skills to help me
> there  :-)

You have to be realistic.  THAT'S NOT GOING TO HAPPEN.

THere have been long threads on the LGDG (Linux Games Developer Group) about
the lack of motivated artists who'll work for nothing.  Response from the
artists strongly suggests that what few of them WILL help are not likely to
jump into just any project - they are going to look for projects with experienced
programmers with a proven track-record.

Even if you did find such a person, they are not going to be your 'art slave'. You
won't gain much support if you say things like "Paint me a radar display that's
64x64 pixels, translucent and looks like a spider-web".  If you are *REALLY*
lucky, you may find an artist who will be interested in designing things like 
spaceships or big-breasted aliens women with three heads and forked tongues...but
they are unlikely to be interested in doing these kinds of silly little jobs.

You just need to practice and learn GIMP.  It's not that hard to draw things
like instruments, little icons and such like.
 
> > > Also, I could go and say, hey, here's KobScene, an open source
> > > SceneGraphHandler, for whoever might need it.
> > > It's also a possiility to benchmark different scenegraphs.
> > > Just for interest.
> >
> > I guess.  I'd do that at the outset of the project - then pick one
> > and run with it.
> 
> I'd rather want _them_ to do it for me, since I don't have time ;-)

*NOT* going to happen.  You need a dose of realism.

Let me tell you about Tux-A-Quest-for-Herring.

It was the first *ever* 3D game for Linux.  I was 'slashdotted' *TWICE*
(once when I released initial screenshots and again when the game
was ready for release).  I've had 5-star ratings (the best possible)
on every review site I know of (TwoCows, HappyPenguin, etc)..every major
Linux distribution has it on their CD...so I have to imagine that people
generally like it a lot.

I got:

  150,000 people visiting the web site over the first 12 hours.
   15,000 people downloaded it in the first 12 hours.
    1,500 emails complaining/complimenting/thanking me for TuxAQFH
          within the next week or so.
   ...one year later...
      150 people are subscribed to the Tux mailing lists.
       15 people have *ever* offered to help with artwork/music/models.
      1.5 (OK...2 actually) other people have actually contributed
          *anything* to Tux *ever*. One piece of unusable music - and a
          couple of unusable models.  No significant chunks of code at all.
    *NONE* of those things has ever been useful enough to distribute with
          the game.

Now, *you* won't get slashdotted - they don't report freeware game releases
anymore.  So, how many people do you think will be helping you at the end
of the day?
 
> > > And: Quake, Quake, Quake, all people in my real life play Quake.
> > > There are a lot of players, editors, engines - I just hope by
> > > saying - "hey, my game uses free quake" to attract those people,
> > > especially the ones that design models to my game...
> >
> > Well - I doubt it.
> 
> But what happens, if the brave Starfighter Pilot lands on some weird
> planet and has to rescue some mamsel by simply going afoot, it'd
> be a chance to use all those quake-stuff for this subtype of
> KobayashiMaru.

But do you really believe that as a beginner 3D programmer, you will manage to
write a single game that spans deep space PLUS flight sim PLUS hand-to-hand
combat and integrates all those seamlessly?  Not one single game throughout
the entire history of game making has ever been that ambitious.  Not one.
Remember that *very* likely you'll be doing it single-handedly with no
artistic or music input?

I don't mean to try to put you off - but

a) Be realistic about what you can achieve in reasonable time.

b) Know your limitations.

c) Start with something small - and you *might* get it finished
   to the point where it's playable.

It would be better (IMHO) to concentrate on making a good space
game - and forget (for the moment) about the other things.

Remember - it took 100 people working full-time 5 years to create
Mario'64.  You have about three times that amount of work.  You should
be finished in about 1500 years.
 
You are still learning the basics like matrix algebra and that text
is S-L-O-W.

> Are there any FlightGear developers reading?

Several.

> I'd like also to include your 3D Terrain Rendering Engine in my game,
> if it could be easy to access it like
> 
>    terrain.init(terrain_data_filename)
>    terrain.draw(sgMat4 camera_position)
> 
> please show me a way to easy access the code, or write me a class
> that does this thing for me.

The 'terragear' spin-off project is like that - but if you are
planning to have things zoom around at several times the speed
of sound, you'll need a LOT of terrain.  Many, many megabytes.
 
> Dear Steve, you should also be aware that at some time in the
> future, your game Tuxkart will be playable from within KobayashiMaru
> (but maybe with other focus).

OK...maybe.  TuxKart is a VERY simple game...4,000 lines.
 
> This will be done by loading the tracks and buildings as 'world' object
> into KobayashiMaru, extending SpaceObject to KartObject (routines
> MoveShip/PitchShip) that behaves like a Kart, write a KI KI_KartDriver that drives this
> thing and - pop - KobTuxkart.

That's *VERY* naive.  Have you thought about collision detection yet?

Scale down your rhetoric until you've done it.  You are a *classic* newbie
who understands just enough to think they can take over the world.  When you
have a couple of *finished* 3D games done, come back and tell me how easy
this *actually* is!

> What you'd think I should do?

Look before you leap!

> Tell sourceforge to stomp it all in, homepage, ftp, mailing list
> and create it all new with new name, two weeks after opening?

Yes - what do you have to lose?  Changing the name everywhere and
deleting the references to X-wings and such won't be more than
a couple of hours work - open a new sourceforge account under the
new name copy everything over - then tell their support guys to
dump the old site because it's been superceded.

> I don't like that idea, I don't like your scenario either :-(

Well - it's your call.

It could be worse.  I dumped an entire game (Harry Potter/Quiddich)
when I got 'cold feet' over the legalities after the book became a
phenomenal success and they announced a feature film!

> > We live in a litigous society...and the owners of the Star{Trek,Wars}
> > rights are amongst the nastiest of people to upset.  Just don't put
> > Mickey mouse ears and a Coke 'swirl' on your spaceships!
> 
> Moment - thank you very much for showing me how to make money with
> my game :-)

   :-)
 
> IF I probably contact Coke and Disney and tell them - "Would you
> like to sponsor me?", they'd probably give me money to do exacly like
> that, and you'd wonder how much advertisement you'll see in space ;-)

Have you seen the adverts in TuxKart's first level?  Look at them
*carefully* and wonder how I chose them!  My lips are sealed.

> Please be aware that I'm only joking.

I'm not!

-- 
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] An example of ssgVtxArray usage

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

pretty cool. i wrote a glut main() for it and added it to plib cvs (in
examples/src/ssg/tux). it's a good example of how to manually setup a leaf
without using a loader.

--Dave

> I've uploaded a very preliminary version of a useful class for
> animation in games.  Its also useful for seeing how ssgVtxArray
> can be used and its limitations.
> 
> http://vallevand.homepage.com/plib/WavingFlag.h
> http://vallevand.homepage.com/plib/WavingFlag.cpp
> 
> The class implements a flag waving in the wind.  Its optionally
> textured on both sides.  The flag is 1.0 by 1.0 units and is in
> the y-plane with lower left coords (0,0,0) and upper right coords
> (1,0,1).  The wind blows from -x to +x.  You can translate and
> scale it as needed, and rotate it around the z-axis for wind
> direction.  But, it should not be rotated about other axis because
> you'll loose the effect.  
> 
> The class illustrates ssgVtxArray usage to share vertex info
> between triangle strips.  It also illustrates one limitation:
> if a vertex is used for both faces of an object, the normal for
> the vertex will be outward-facing on one side and inward-facing
> on the other.  So far, this hasn't caused any problems for me.
> 
> Regards.
> Mark K Vallevand   ma...@rs...
> Never try and teach a pig to sing: it's a waste of time, and it annoys
> the pig.

RE: [Plib-devel] PLIB developers needed.

[Norman V. <nh...@ca...>]

Steve Baker writes:
>
>Would anyone else like to step forward as an active developer
>(with CVS write access) ?

I can keep the Cygwin stuff upto date for us

I am nhv at sourceforge 
( check prettypoly developers if more info needed )

Norman

RE: [Plib-devel] PLIB developers needed.

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

Steve wrote:
> There is an element of trust here.  I obviously have to give up a
> measure of control - and yet trust that someone whom I give write
> access to isn't going to make a horrible mess of the architecture.
> 

What follows are a few things I've learned working on PLIB.  If you look
through the archives of this mailing list you'll find discussion and reasons
for them.

1) coding conventions
2 space indent
for public symbols in PLIB module 'XX'
(where 'XX' is: SL, SSG, SG, PU, FNT):

#define's, enum tags -- XX_ALL_CAPTIALS
variables -- all_lower_case
functions/classes/structs/typedefs -- xxMixedCase

for private functions, use all_lower_case unless they would pollute the name
space in which case you should use _xxMixedCase
(note the leading underscore).  if a variable pollutes the name space, use
_xxMixedCase.

2) don't use C++ exotics like STL, templates, exceptions, operator
overloading, and iostreams to make porting easier.  if you love that kind of
stuff, you can always wrap plib in your app code.

3) don't add dependencies.  PLIB requires OpenGL and optionally GLUT.  this
is an important and valuable design goal of PLIB.  It sure made it easier to
get PLIB running on a game console because I had to implement a subset of
just *one* API (OpenGL) for the native architecture.
http://www.pond.net/~davem/tinylib

4) For any major change, please consider posting to this list *first*.
Other developers may have a more elegant method of implementing the same
thing or already have a patch that they didn't think anyone else was
interested in.  Perhaps the major change you are thinking about does not
belong in PLIB at all and would be better off in an auxilliary library or
example.

--Dave

Re: [Plib-devel] PLIB developers needed.

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

Wolfram Kuss wrote:

> What things need to be done?

Well, just incorporating contributions and chasing other leads
could be a fulltime job.

> However, if I would be become a plib-developer,
> prettypoly would stay my main project.

Sure - and I'm hoping that if I can offload some of the PLIB
work, my PPE efforts could be larger.
 
> BTW, it *MIGHT* be that I have to rewrite the
> *.x loaders/writers in Mdi_edit in some time, then I would
> probably write some for plib at the same time.
> *.x is Micro$ofts Direct3D file format, mainly used for games.

More loaders will *always* be welcome.

And wearing PPE hat for a moment - some WRITERS would be v.welcome
too!  Writers are generally MUCH easier to write than loaders...a
VRML exporter would be cool for PPE.

A *very* simple example program that coupled all of our loaders to
all of our writers with a simple command-line or pointsy-clicksy
file selector would result in a file conversion utility that would
be a service to mankind.

> Dave (or anybody else), if I want to see how a loader/writer works,
> which should I look at? It should be farily easy to understand,
> fairly complete and the format should be fairly straight-forward
> (list of vertices/list of faces).

Probably the AC3D loader then - it's an ASCII input format - which makes
life easier.

> Its absolutely not clear I would do this, but if then I will probably
> only implement the ASCII-*.x-format, not the binary one.

Well, I've added you to the developer's list...let me know if you want
me to take you off again!

-- 
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] KobayashiMaru 0.2.9 for BeOS

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

Hi,

KobayashiMaru 0.2.9 has now been compiled for Beos5
and is available from my Homepage.

I had to patch plib-1.3.0 to compile plib - Beos
doesn't seem to have a glXContext , so you just have to put some
#ifndef BEOS
in puInit and ssgInit,
it simply works without this glXContext - check.

Alex

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

Re: [Plib-devel] PLIB developers needed.

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

Gil Carter wrote:
> 
> I'm registered as gilcarter at Sourceforge.  If Steve adds me to the CVS
> write crowd, there's no more excuses...

Consider it done.


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

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

"Vallevand, Mark K" wrote:
> 
> I'm supposed to have CVS write access to PLIB, but it doesn't
> work.

Well, I've checked - and you certainly ARE on the write access list:

   markus5   - Mark
   mcdave    - Dave
   sjbaker   - Steve
   sps196    - Sam

There are at least 4 HOWTO/FAQ documents specifically for Windoze users
somewhere on Sourceforge...erm....here:

       http://sfdocs.sourceforge.net/sfdocs/

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

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

Fay John F Contr AAC/WMG wrote:
 
> What does being a PLIB developer entail?

Well, any or all of the following:

1) Having great ideas - turning them into working code - committing them.

2) Getting great ideas from other people - turning them into working code - committing them.

3) Getting code from other people - making sure it works - committing it.

4) Committing patches from other people who aren't registered developers but
   whom we trust.

5) Documentation.

6) Perhaps volunteering to take over and "own" one of the library chunks in PLIB.

7) Perhaps taking over maintenance of the PLIB web site.

8) Perhaps taking over the main release mechanism for PLIB.

Right now - I'd be happy to let anyone I know moderately well from past
history do any of the first five things - for the last three, it would
have to be someone I know *WELL* and who has contributed quite a bit of
good stuff.

>  I'm interested in supporting PUI,
> but my day job keeps getting in the way.

Yep - my problem in a nutshell.

>  How many hours a week are you talking about?

As many or as few as you can contribute.  You could make
a useful impact with just a few hours a week.

> What sort of things does a formal developer do?

Well, the only difference between a formal developer and a typical
list member is that you have access rights that allow you to change
the code/examples/documents for PLIB without having to go through
Dave or myself to get changes actually committed.

There is an element of trust here.  I obviously have to give up a
measure of control - and yet trust that someone whom I give write
access to isn't going to make a horrible mess of the architecture.

You have to trust that I won't go and undo all your hard work after
you've gone to all the trouble of committing it.

Dave and I seem to agree on most things - so it's going smoothly
so far...we need to go carefully to avoid personality problems
in the future.

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

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

Wolfram Kuss wrote:
> BTW, it *MIGHT* be that I have to rewrite the
> *.x loaders/writers in Mdi_edit in some time, then I would 
> probably write some for plib at the same time.
> *.x is Micro$ofts Direct3D file format, mainly used for games.
> Dave (or anybody else), if I want to see how a loader/writer works,
> which should I look at? It should be farily easy to understand,
> fairly complete and the format should be fairly straight-forward
> (list of vertices/list of faces).
> Its absolutely not clear I would do this, but if then I will probably
> only implement the ASCII-*.x-format, not the binary one.

i couldn't find examples of the ASCII-*-x format, only references in the
documentation.  Tons of binary .x format examples but that is yucky.

ssgLoadAC.cxx contains the most stable, easy to understand, and complete
loader in SSG.  It is what I used to start writing new loaders/exporters.

I'm trying to unify the loaders around ssgParser.cxx which keeps track of
file/line information for error messages and tokenizes each line.  ssgParser
also can track brace/block levels.  I'm using this for ASE and plan on using
it for WRL.  Eventually, I want to go back and fix OBJ,DXF and TRI to use
this.  So... you may also want to look at ssgLoadASE.cxx for a more complex
example.

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

[Plib-devel] ssgVtxArray and ssgIndexArray using shorts instead of ints

[Vallevand, M. K <Mar...@UN...>]

I started to make a change to allow ssgVtxArray to work with index
arrays of either shorts or ints, but that proved to be awkward.  So,
I changed ssgVtxArray and ssgIndexArray to use shorts instead of 
ints.  Wonderful!  There were no changes required in any of my
programs using indexed vertices.  This looks like a painless change
to programmers, so I'm going to put it in.  I've got my own problems
with CVS, but I should have things solved soon.  Look for this
change in the near future.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.