[Plib-devel] An example of ssgVtxArray usage

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

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.


> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Monday, August 07, 2000 8:16 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] plib, glut and sdl
> 
> 
> Ben Woodhead wrote:
> 
> > A while ago I was talking with serveral people regarding 
> glut 3.7 (game
> > glut). From what they where saying is that the glut 
> libraries can't handle a
> > large amount of load and would not be good to us in games.
> 
> This nonsense is repeated often - but NEVER with specific details of
> WHY and WHERE GLUT is supposedly so slow.  In fact, it's 
> complete B.S which
> has "become true" by virtue only of having been oft repeated.
> 
> You only use GLUT calls to open the windows initially - to 
> read low-speed
> peripherals (like keyboard and mouse) - and to handle window events.
> 
> Games dont *do* enough of those things for GLUT to be a load.
> 
> If in doubt, look at the GLUT code for the main event loop - 
> it scarcely
> executes a dozen lines of C per event.  I would be VERY 
> suprised if GLUT
> consumed more than a hundred lines of code per frame.  On 
> anything post-Z80
> that's negligable!
> 
> The *only* place I've heard remotely believably, specific 
> complaints - is
> that under Windoze, GLUT uses one of the less good API's for 
> reading the
> mouse.  I'm told that red-hot Quake-heads can tell the 
> difference...however,
> who has done the same studies for alternative window-handlers 
> like SDL?
> 
> Honestly, I'd use GLUT - or possibly even 'freeglut' 
> (freeglut.sourceforge.net).
> If you genuinely find the mouse mechanism to be too slow 
> under windoze - then
> switch to the fast mechanism and offer your change as a patch 
> for each of those
> versions of GLUT....I don't think you'll ever find a need to do that.
> 
> > So I was able to hack the tux_example to us SDL instead and 
> it seemed to
> > work fine, but plib was still compiled to use glut. I also 
> read some plib
> > docs and somewere I read that plib can be used with or 
> without glut, is that
> > the case. Would sdl be a better option then glut, would it 
> take a lot of
> > work to change plib to sdl instead.
> 
> Well, the only things PLIB uses GLUT for is:
> 
> a) In PUI: Finding the size of the current window.
> b) Optionally - in PUI: to render fonts when you don't
>    want to use PLIB's own font library.
> 
> However, if your only reason for going to all this trouble is because
> you've heard that GLUT is no good for games - then I'm afraid you have
> been wasting your time.
> 
> Morover (and more seriously IMHO), SDL is not generally installed by
> default with OpenGL implementations - where GLUT is.  Hence you've
> added a significant additional dependancy to your program - which will
> make it much harder for your poor users.
> 
> I've had a heck of a lot of problems with SDL in applications I've
> downloaded.  Because SDL is (like PLIB) made of a bunch of component
> libraries, but (unlike PLIB) releases each component out-of-sync
> with the others, you tend to find that each game needs a different
> set of versions of the sub-packages.  Since some versions of some
> SDL modules are incompatible with other versions of others - I think
> that maintenance of a package that uses SDL is going to be quite
> challenging!
> 
> Also, I don't think SDL is as portable as GLUT...although I could
> be wrong about that.
> 
> SDL is getting quite popular though - so I suppose these things
> will eventually settle down.
> 
> -- 
> Steve Baker   HomeEmail: <sjb...@ai...>
>               WorkEmail: <sj...@li...>
>               HomePage : http://web2.airmail.net/sjbaker1
>               Projects : http://plib.sourceforge.net
>                          http://tuxaqfh.sourceforge.net
>                          http://tuxkart.sourceforge.net
>                          http://prettypoly.sourceforge.net
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
>