plib-users

[Plib-users] Suggestions for coming plib version

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

Hi,

I've some suggestions to your coming plib version, I also read
plib-devel
and there's a lot going on in it - fine!

I cannot check out the latest version via cvs at the moment ('technical
difficulties' on my side, my latest snapshot is 9th Sep) , so what I've
got to say could be outdated now.

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

* is the documentation updated to show the features of the new stuff?
I haven't found puFilePicker, for example

* If got another monitor, the colors seem to be better now, but I would
still like Steve to change the colors a bit (if not for me, maybe for
others)

* there were no puInput examples in examples/src/pui
I have problems with puInput (can't click on them), please provide me
with an example, let's say two puInput fields which can be clicked

* I also maybe need some new 'easy' widgets.
First, thanks to Dave for implementing puFilepicker, although I have
to admit I didn't use it yet - please provide docu (see above)
I need another widget like puFilepicker, that's what I call
puScrollList - a widget that displays a scrolling list, with a scrollbar
at a side.
My puScrollList is just a 'evil hack' to use in my program, you could do
that
better - as Dave has shown with puFilepicker.
But he went a 'bit too far' - I need a widget like puFilepicker, but I
need
also a widget that just takes an array of pointer to string as an input
and displays them and tells which one get's clicked etc.
I hope you understand what I mean.

* I read in your plib-devel list something about ssgaShape (also found
no docu)
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.
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.
Idea: for a 3d object, maybe one could make the lasershot not a long
rectangular thing but a triangular thing - player won't notice.


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


Alex

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

Re: [Plib-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