Re: [Plib-users] Suggestions for coming plib version

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

Alexander Rawass wrote:

> * the file doc/index.html seems to be Steve Bakers private Homepage, not
> the plib Homepage/index page

That appears to be fixed now.
 
> * is the documentation updated to show the features of the new stuff?
> I haven't found puFilePicker, for example

It's too new.  All of PLIB's documentation needs updating.  It really
hasn't been touched since V1.0.0 or so!
 
> * I read in your plib-devel list something about ssgaShape (also found
> no docu)

Also too new.

It's not hard to understand though - since it's all in the style of
the other SSG functions - and derived from ssgBranch.

> In my game, a Space Fight Sim, you'll see a real of lasershots.
> The easiest lasershot is just a rectangular and long and either red or
> green,
> right now I am using an ac3d object which I have constructed - it has
> probably too many polygons, what do I now.
> What I want from you is probably something like an ssgaShape - a ssg
> object which looks like a 'lasershot' in a given color, but renders the
> _fastest_ way a such-looking thing can render.

You will probably find that a nice wide GL_LINE primitive with GL_LIGHTING
disabled is the best way to do this.

Using polygons has the problem that for thin things like laser shots, they
tend to get smaller with perspective and they vanish "between the pixels",
break up and generally look terrible.

> It doesn't even need to be 'real 3d' anyway - it goes fast enough that
> the player can't see the diference between a 3d object and a fat 2d line
> moving in his sight.

So use a fat GL_LINE!

You might find that drawing a wide - but translucent line - followed by
a narrower, opaque line - possibly in a slightly lighter colour - will
make them look "hotter".  You'll need to experiment.

SSG doesn't support glLineWidth - so you'll have to set it in a draw
callback.  Personally, I probably wouldn't use SSG to draw laser bolts
anyway.

> Idea: for a 3d object, maybe one could make the lasershot not a long
> rectangular thing but a triangular thing - player won't notice.

But it'll alias still worse.

The nice thing about GL_LINEs is that you can control their widths
(in pixels) no matter what their range is...yet they are still in 3D
and are occluded properly in Z.

> So thanks to plib-devel for their work - I have to say (getting
> back to 'Bloatware') that with plib growing that much, it gets
> harder - if not impossible - to optionally switch to another scene-
> graph, so the future will make Steve's words come true :-))

My only concern with growing PLIB is that we manage the transition
from "Simple - but Effective" to "Comprehensive, Robust - but still
Approachable by the beginner".

Things can only be described as 'bloated' when they are larger than
their functionality appears to warrant - or when their functionality
grows to the extent that a majority of users don't use or understand
a vast percentage of the API - so they *appear* to be larger than
their *useful* functionality warrants.

That's certainly something to be guarded against.

When you look at (say) the Windoze Joystick API - there are at least
three different ways to read the joystick - all totally incompatible.
Why?  Because they initially didn't think beyond two 2 axis joysticks
each with two buttons.  Then when they realised their mistake, they
simply froze the old API and made a new one that could handle (IIRC)
4 axes and 8 buttons...then sticks with even more axes and buttons
came along and yet another layer of API was needed.   If they had
only stopped to think at day one, they could *easily* have allowed
for arbitary numbers of axes, sticks, buttons, etc - and that API
would still be valid today.

Hence, if we wish to keep PLIB from developing those kinds of warts,
we need to *carefully* think about keeping each new feature as general
as it possibly can be.

I'm not pretending we don't make those kinds of errors in API design,
but by paying close attention to getting the API right, I maintain
that 'bloat-reduction' will naturally follow.

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