plib-devel

Re: [Plib-devel] ssgVtxArray fixes.

[Eero P. <epa...@ko...>]

Steve Baker wrote:
> 

> 
> Well, doing *math* on ints is probably faster than shorts - but this is largely
> a matter of RAM bandwidth and cache sizes and such.  I'm no expert either - but
> I was under the impression that for simple indexing and such, shorts can be
> faster.
> 

At least Pentium Pro (and I suspect this might be true for
Pentium II / III also) can suffer badly if memory accesses
to 32 bit and 16 bit quantities are interleaved.

Something to do with read accesses not been able
to check the outgoing write queue and thus requiring a 
queue flush, or something like that...

Still the smaller memory footprint might be worth the trouble,
but I have seen this problem as spikes in the VTune display.
(I have also seen spikes caused by cache misses, and 
they can be worse)


		Eero

RE: [Plib-devel] ssgVtxArray fixes.

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

Steve Baker wrote:
> Yep - when you called 'glDrawElements' you said:
>
>    glDrawElements ( gltype, num_vertices, GL_UNSIGNED_INT, ii ) ;
>                                           ^^^^^^^^^^^^^^^
>                                      Change this to
>                                      GL_UNSIGNED_SHORT
>
> ..you can also pass GL_UNSIGNED_BYTE - but I think that's *too* small.
>
> This would be a non-reverse-compatible change though - how many people
> are using ssgVtxArray and would be upset by such a change?

I'm using it but would welcome any change that makes it more efficient.  I
wasn't aware of the 32K limit of points in a leaf you mentioned.  Where does
that limit occur in the source?  Should we check that limit when models get
loaded?

--Dave

RE: [Plib-devel] plib, glut and sdl

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

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

Steve Baker wrote:
> Honestly, I'd use GLUT - or possibly even 'freeglut' 
> (freeglut.sourceforge.net).

Yep. The best route is to use/contribute to GLUT or 'freeglut' because
then improvements can be shared with everyone.  But if you want a quick
fix for windows...

GLUT is such a simple API that it's a snap to implement yourself if
you don't think it's fast enough.  I used Ryan's code here
	http://members.home.com/borealis/gldemo.c
to implement GLUT for windows.  Ryan only uses 16 bitsPerPixel and
16 bits for zbuffer.  He also changes the task priority to get more
frame rate.  It doubled my frame rate.  Ryan knows all the tricks.

--Dave

Re: [Plib-devel] ssgVtxArray fixes.

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

Chris Phillips wrote:
> 
> >Is there some reason why the index array is an array of 'int'?  Since the
> underlying
> >SSG classes don't allow more than 32k vertices/normals/colours/texcoords
> per leaf
> >node - it seems unlikely that this would be needed - and there are
> certainly speed
> >improvements to be had from using a 'short' index array.
> >
>         I was under the impression that dealing with ints is usually faster that
> shorts on
> 32 bit processors. Are you talking about speed improvments from code
> optimization or something
> else like data cacheing?

Well, doing *math* on ints is probably faster than shorts - but this is largely
a matter of RAM bandwidth and cache sizes and such.  I'm no expert either - but
I was under the impression that for simple indexing and such, shorts can be
faster.

-- 
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] ssgVtxArray fixes.

[Chris P. <bi...@se...>]

>Is there some reason why the index array is an array of 'int'?  Since the
underlying
>SSG classes don't allow more than 32k vertices/normals/colours/texcoords
per leaf
>node - it seems unlikely that this would be needed - and there are
certainly speed
>improvements to be had from using a 'short' index array.
>
	I was under the impression that dealing with ints is usually faster that
shorts on 
32 bit processors. Are you talking about speed improvments from code
optimization or something 
else like data cacheing? 

	Regards
	  Chris.

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

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

Alexander Rawass wrote:

> > Also, after all you said about the FAQ page, you didn't provide a
> > link to it!
> 
> My Homepage is just building up - first public version.

Yes - I understand - I'm really just trying to help!

> > The artists working on StarTrek must have wanted to go home early on
> > the day they designed the Borg ship!  :-)
> 
> _AND_ the idea of the borg is stolen from Perry Rhodan, they call them
> 'Posbis'

Really!  I don't remember that.

> > They announced 'MiniGL' (which runs on PalmPilot) last week at SigGraph.
> > It's likely to be *horrificly* slow - and with only 5-grey-shade monochrome
> > with no Z buffer, I don't think you *really* want to go there yet.
> 
> Sitting in the railway, playing a game _exactly_ like Elite?
> No Problem!

Yes - it might just manage that at reasonable speed.  Wireframe would work well
and you wouldn't have to worry so much about Z-buffering.
 
> > How many polygons are you drawing - and what kind of frame rate are
> > you getting - with what percentage of your CPU time going into ssgCullAndDraw?
> 
> With lots of objects it goes very high (yes,not very precise).
> But I have yet models with far too much polygons and have no level of
> detail (due to shortage of models) - I didn't look, is there a routine
> like countPolygons(scene/entity)?

No - but you can easily hack one into SSG.

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.
 
> > Looking at your screenshot, I'd guess that a TON of time is being wasted drawing
> > the text.  It *looks* to me like it's being drawn using GLUT's fonts - which
> > are REALLY slow on most graphics cards.
> >
> > You really need to draw text using textured quadrilaterals - for which there
> > is (of course) a PLIB library 'FNT'.
> 
> I read this on the plib page, but I hat a snippet of code that worked,
> I will time it and probably change.

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

Think about it.  For EVERY letter you draw, you are sending (say) an 8x10 pixel
rectangle of pixels to the frame buffer.  With full RGBA, that's 8x10x4 = 320 bytes
per character.  You are drawing a couple of hundred letters - so you are downloading
maybe 64Kbytes into the graphics card every frame - several megabytes per second
at reasonable frame rates.

On the other hand, if you use textures, you have all those letter shapes stored
in a texture map that's already down on the card.

More than that, many PC graphics cards have to 'flush' their polygon buffers in
order to allow the CPU to get access to the frame buffer - that can cause a major
stall in your CPU when you first start drawing bitmapped characters.

Anyway - this is a REALLY common problem for people who are doing this for the
first time.

Come to think about it - one of my FAQ documents is all about this stuff.

> > 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.
 
> > Also, that spider's web looking thingy - I presume it's a radar display - is
> > consuming a LOT of throughput if it's being drawn as OpenGL lines - there appear
> > to be at least 120 lines being drawn.  Most PC graphics hardware does a very poor
> > job of drawing lines - so you'd be better off painting a really nice radar display
> > in GIMP (or whatever paint program you prefer) - and drawing that as a single
> > textured quad.
> 
> 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.
 
> > SSG already acts as a portability layer - why go and build a portability
> > layer ON TOP of a portability layer?
> 
> Some time I ago I tried to download/compile many 2D-linux games, and
> some of them seemed to me to have exactly this feature, to compile
> for different bitmap-handling libraries, and I wanted this feature.

Yes - but for 2D, that's necessary - you have console mode, SVGA, GGI,
X-windows, etc.

For 3D, there is exactly ONE low level standard for Linux...and most
other OS's - OpenGL.  Hence the need to be able to run on multiple
standards is almost zero.

> 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 don't know about glDoom or Aftershock - but Quake/Quakeforge are tuned
> > for all the fancy flickering torchlight lighting effects and 'portal'
> > clipping that being in a dark closed space entails.  That's pretty much
> > the opposite of a space game.
> 
> Those objections have been already told to me bu a friend, but if you
> imagine space as one giant room with no portals, how fast is the
> part that renders this? Interesting question for me.

Well, in the end you are shoving polygons into OpenGL as fast as you
can.  Testing to see if there are other portals to clip against can
really only slow you down.
 
> 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.
 
> > There are also some others that you missed - OpenSG for example.
> 
> Bah!
> 
> I've checked their Homepage for over three months, it didn't change,
> no bits of code. Nothing exept announcements.

I spoke to the guy who wrote it at SigGraph (actually - I think he's
subscribed to this list)...I think it has promise - although perhaps
not in the area that PLIB is intended for.
 

> >  * I think it may be unfair to characterise PLIB as the source
> >    of your slowness.

> No, it's the _third_ source:
>    1. too many polygons due to bad (3ds-converted) models
>    2. my own code (I know where I loose time)
>    3. plib
>    4. but there's no fourth ;-)

Well, probably:

     0. Bitmapped fonts - and LOTS of text.
 
> But maybe it's just so that I think that a game like a Star-
> Fighter game will have to be faster and more complex than
> a game like Tux.

I doubt that you'll need as many polygons as Tux - at least
in deep space.  I guess if you are skimming along the surfaces
of planets then you have something more like a flight simulator...
like FlightGear for example...hmmm - I wonder what that's
written in?  (Hint: Begins with a 'P')

> Actually, I've mo idea.

Well, exactly - and that's why I resent you saying that PLIB
is
slow.  People who may be thinking of using PLIB will use a search
engine to look for other people who use it.  If they find your
page and it says PLIB is slow then they'll run a mile.

So - you have to be scrupulously accurate.  Your web page should
say "My game is slow - I don't know why."....So quit telling the world
that my library sucks - at least until you manage to show that it
really does suck - and in a way that we can't easily fix.

> >  Personally, I accuse
> > all that text you are drawing.
> 
> I will time that. And bite my ass if it's true.

Well - be careful how you time.  It's tricky to measure the time
to draw the text because you'll be unable to time the all-important
pipeline delays in the graphics hardware.

The best thing is just to comment it ALL out and see how much faster you
run without it.

It's possible that your other problems outweigh this one - but from
my experience, it's a MAJOR hit.

That's why I went to all the trouble to write the 'FNT' library. FlightGear
was getting *horrible* frame rates - due to just a couple of lines of text
in the HUD display - but you have DOZENS of lines of text.
> I am a novice in 3D maths as well as GL as well as games programming.

We were all there once.

> If you look at the code, you'll find many really nasty things that
> shouldn't clearly be like that, but I have to admit I am a lazy
> programmer and tend to write first quick&dirty, and then improve it.
> AND there are places in the code were I simply stopped , because
> I had problems and wanted to write on another piece of code.

That's a GOOD approach.

Don't optimise something unless it's going to give you a significant
speedup....and if you are doing it for free - do what YOU find interesting.
 
> Okay. Ashes on my head. Lot's of ashes. I hope you're non-smoker.

Yep.  There is no need to apologise - just fix the problems.

> I am just starting to hope that you won't point out too many bad
> codelines, please forgive a youngster.

I don't have time to read your code - heck - I don't even have time
to read my *own* code!  Sorry.
 
> >   These are things that it's easy enough to change - and keeping
> > it 'clean' of other people's intellectual property is really
> > important for GPL'ed software.
> 
> There may come a time when it's necessary to say things like
>    sed 's/KobayashiMaru/TuxFleet' `find .`
> but I have chosen to wait.

Yep - that *could* work...but it may not be enough once you have
licensed a gazillion copies to people under GPL.  You could
be liable for (say) a $10 licensing fee for every copy you
gave away!  15,000 people downloaded Tux_AQFH.  Think about it!

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!

Good luck!

-- 
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] ssgVtxArray fixes.

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

"Vallevand, Mark K" wrote:
> 
> I'll try it ASAP.  I wrote the ssgVtxArray, and use it a lot.  I'm glad
> that you found and fixed the problems.  I haven't looked at the code for
> some time.
> 
> As for index arrays of 'int', that is just ignorance.  If the OpenGL
> calls will take arrays of 'short', I see no problem with that change.

Yep - when you called 'glDrawElements' you said:

   glDrawElements ( gltype, num_vertices, GL_UNSIGNED_INT, ii ) ;
                                          ^^^^^^^^^^^^^^^
                                     Change this to
                                     GL_UNSIGNED_SHORT

..you can also pass GL_UNSIGNED_BYTE - but I think that's *too* small.

This would be a non-reverse-compatible change though - how many people
are using ssgVtxArray and would be upset by such a 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] plib, glut and sdl

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

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

Re: [Plib-devel] KobayashiMaru & plib

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

Alexander Rawass wrote:
> 
> there is a new game in town that uses plib:
> 
>    Kobayashi Maru      kobayashimaru.sourceforge.net
> 
> a Mailing List kob...@li... has been
> created
> 
> It's goal is to write a flexible, extensible, multi-platform (blah blah
>  blah :-) Space Fight Simulator in 3D

Have you had a look at Parsec (http://www.parsec.org)?

I know that they don't publish their source (but IIRC they plan to
release the game itself for free)...

It'll be at least interesting to get some new ideas. They've also got a
few papers online (they are CS students; Parsec is their 'playing
ground' for their ideas) which are very interesting IMHO.

CU,
Christian

RE: [Plib-devel] ssgVtxArray fixes.

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

I'm going to get the latest CVS tonight, and try it out.
 
Then, it should be a simple thing to either:
- change the index array to short, breaking most code using ssgVtxArray,
- or, add a new index array of shorts and updating ssgVtxArray to handle
both
  types, and existing code using ssgVtxArray will continue to work.
 
If I'm happy, I'll even try to check it into CVS.
 
Then I'll try to clean up a couple of utility classes I'm using in my new
game,
so they can be shared with others.  But, that is another message.

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: Dave McClurg [mailto:Dav...@dy...]
Sent: Monday, August 07, 2000 12:33 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] ssgVtxArray fixes.



Steve wrote: 
> I've fixed a small mountain of errors in ssgVtxArray... 
<snip> 
> So, that's all committed. 
thanks! 

> Is there some reason why the index array is an array of 
> 'int'? 
> Since the underlying 
> SSG classes don't allow more than 32k 
> vertices/normals/colours/texcoords per leaf 
> node - it seems unlikely that this would be needed - and 
> there are certainly speed 
> improvements to be had from using a 'short' index array. 
> 
not AFAICT. Mark? we should make it a 'short' like you say. 

> Anyway - could someone who uses ssgVtxArray please try it out 
> and let me know if I broke something. 
> 
i tested all my models out with the new source and they still work 

happy plibber, 
--Dave 

RE: [Plib-devel] ssgVtxArray fixes.

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

Steve wrote:
> I've fixed a small mountain of errors in ssgVtxArray...
<snip>
> So, that's all committed.
thanks!

> Is there some reason why the index array is an array of 
> 'int'?
> Since the underlying
> SSG classes don't allow more than 32k 
> vertices/normals/colours/texcoords per leaf
> node - it seems unlikely that this would be needed - and 
> there are certainly speed
> improvements to be had from using a 'short' index array.
>
not AFAICT. Mark? we should make it a 'short' like you say.

> Anyway - could someone who uses ssgVtxArray please try it out 
> and let me know if I broke something.
>
i tested all my models out with the new source and they still work

happy plibber,
--Dave

Re: [Plib-devel] plib, glut and sdl

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

Hi Ben,


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

I can't comment on how much quicker (if at all) sdl would be, but plib relies very little on glut.  The only library to my knowledge
that uses glut is pui and that only uses the glutGet functions for window size.  ssg is the most complex library in the pack and
that simply issues OpenGL commands, relying on the fact that a valid openGL context already exists.  Whether you create that with
glut or sdl or native Win32 or GLS or whatever doesn't matter.

Sam

[Plib-devel] Re: KobayashiMaru & plib

[Alexander R. <ale...@us...>]

Hi,

Steve wrote:

> I'll check it out - do you have a small logo that I could put
> on the PLIB home page as a link to the game?

Not yet. Maybe soon.

> On the "math_help" page - where you are heaping praise on my
> FAQ page and running me into the ground for my web-organizational
> skills, you describe me as a "non-professional" - that's not too
> accurate.  I write flight sim graphics for a living.

I will correct that :-)
That's the thing about the web:
you see someone's page, you don't read careful enough, you make
certain assumptions, and in the end the reality is completely
different from what I had expected. I don't know why.
Maybe I should sit down in a corner and be quiet ;-)

> Also, after all you said about the FAQ page, you didn't provide a
> link to it!

My Homepage is just building up - first public version.

> The "matrices can be your friend" document is an example one of
> those documents you either love or hate.  Several mathematicians have
> come close to death threats over it.  Offers of 24hr kissings are
> also not as uncommon as you might expect.  :-)
> 
> I came across that explanation for how a matrix works completely
> by accident.  When I was just starting out doing 3D, I was
> blinded by the inscrutability of matrices - so I decided to try
> to invent a new way to do 3D transforms.  I wanted to think about
> what happened to the unit cube - and then use extrapolation to
> figure out what happened to the rest of the model.  So, I wrote
> down the coordinates that the unit cube would move to - and
> then said "well, a point at (10,12,14) will end up ten times
> further than where the X axis of the cube went, 12 times where
> the Y axis went and 14 times where the Z axis was." 
> 
> That trick worked *perfectly* - and so - being very proud of
> having discovered this brand new way to do rotation/translation/shear,
> I showed my supervisor...who pointed out that the math in my
> final result was in fact identical to matrix math!  Sheepishly,
> I went back to my desk - realising that I had not stumbled on
> some great new mechanism that would revolutionise 3D rendering.
> 
> Working back carefully, I realised that by writing down the
> final position of the unit cube - I was just writing down the
> rows of the damned matrix that I hated so much. At that point,
> a bolt of lightning flashed from the heavens - angels sang, etc, etc.

I know what you mean.

> I *grokked* matrices by re-inventing them from the ground up.
> "grok" is a good word here.  It means more than "understand" - it
> means that you have 'internalized' not just the bare facts - but
> all the reasons *why* it works, *how* it works, etc.
> 
> Once you have that little unit cube dancing around in your head,
> you can never again forget how matrix math implements 3D transformations.
> 
> If only math teachers could figure out the importance of teaching
> *some* students that way.
> 
> Other people on the other hand, prefer the raw math - and proof in
> a symbolic manner - they don't need to visualise what's going on...
> and they *HATE* my explanation.

I went through the same process of non-understanding as you, lots
of mathematical formula in lectures and no practial connection.

> > So, if there is anyone out there dreaming like me to see X-Wings and
> > Tie-Fighers and Klingons and Borgs and the not-yet-created ships
> > from the Free Stars Foundation (FSF) (their High Priest is a Holy Gnu -
> > a really weird hairy animal ;-) and the TuxFleet (a horde of inter-
> > stellar penguins flying giant Iceberg-shaped glistering StarLiberators,
> > they cooperate in an alliance with the FSF to fight
> > Imperator Raw-Ass The Utterly Evil - aka me, in this game I wanna be
> >  the bad guy)
> 
> :-)
> 
> Well, you'd do well to steer clear of X-wings, Tie Fighters, Klingons
> and Borg because you'll get your ass sued for sure.

I already have the fear of men in suits lining up before my front door.

Haven't you read the slogan of Kobayashi Maru?

"a free Space Fight Simulator for a free Universe"

This is also a joke connected to the name.
Let's see, which Universe is free...
... but I think that honorable Captain Picard would be quite shocked
to realise that he is private property :-)

In some day in the future, the men in suits will appear even in your
dreams and sue you for having used characters of popular series in
your thoughts :-(

> Rip the rotors off the 'tuxcopter' in TuxAQFH and you'd have a
> usable 'StarLiberator' shuttlecraft.  :-)
> 
> I'll ask Oliver if he'd consider building you some spaceships - he
> likes doing stuff like that.  He's away from home until next weekend
> though...be patient!

Would be great!

> > I'll do the coding till my fingers bleed, but please, please, PLEASE
> > 
> >     can't anyone out there design 3D Models for this game?
> > 
> > I need models with few polygons as possible, in low,mid and high detail,
> > and with _lots_ of texture, since that's what a modern Gfx-Card
> > (exept GForce) can take.
> > You can even create more detail levels in between, but I need
> > anything that runs on a todays computer (and - in low detail - even
> > on old ones).
> 
> Fortunately, space ships can be anything from a Borg Cube (Six textured
> quadrilaterals) to the ship in "The Last Starfighter" - which at the
> time was the most complex object ever modelled inside a computer - at
> over 1 million (untextured) triangles.
> 
> The artists working on StarTrek must have wanted to go home early on
> the day they designed the Borg ship!  :-)

_AND_ the idea of the borg is stolen from Perry Rhodan, they call them
'Posbis'

> > I also dream about running Kobayashi Maru on a PDA running linux -
> > ever there ever is something like a 'fastGLforPDA' available,
> > you'd need even low low detail ;-)
> 
> They announced 'MiniGL' (which runs on PalmPilot) last week at SigGraph.
> It's likely to be *horrificly* slow - and with only 5-grey-shade monochrome
> with no Z buffer, I don't think you *really* want to go there yet.

Sitting in the railway, playing a game _exactly_ like Elite?
No Problem!

> There was also an announcement of a formal standard for an OpenGL subset
> that runs on Cell phones and pagers (presumably not *this* generation of
> such devices) - but no implementation is available yet.   :-)
> 
> > Now again thoughts about plibssg performance.
> > I have not much performance on my Athlon500/Tnt2, some is wasted in
> > my code (I know exactly where), but a large part is lost in ssgCullAndDraw().
> > If there is something to be improved in KobScene/KobSceneObject, please
> > do that.
> 
> Well, in TNT-2, all your transform and lighting code is in software,
> so you should expect ~90% of your CPU time (for a typical game) to
> be in ssgCullAndDraw().  Now, if (whilst it's consuming that much
> CPU time), you are not getting reasonable polygon throughput rates,
> we have a problem.
> 
> How many polygons are you drawing - and what kind of frame rate are
> you getting - with what percentage of your CPU time going into ssgCullAndDraw?

With lots of objects it goes very high (yes,not very precise).
But I have yet models with far too much polygons and have no level of
detail (due to shortage of models) - I didn't look, is there a routine
like countPolygons(scene/entity)?

> Looking at your screenshot, I'd guess that a TON of time is being wasted drawing
> the text.  It *looks* to me like it's being drawn using GLUT's fonts - which
> are REALLY slow on most graphics cards.
> 
> You really need to draw text using textured quadrilaterals - for which there
> is (of course) a PLIB library 'FNT'.

I read this on the plib page, but I hat a snippet of code that worked,
I will time it and probably change.

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

> Also, that spider's web looking thingy - I presume it's a radar display - is
> consuming a LOT of throughput if it's being drawn as OpenGL lines - there appear
> to be at least 120 lines being drawn.  Most PC graphics hardware does a very poor
> job of drawing lines - so you'd be better off painting a really nice radar display
> in GIMP (or whatever paint program you prefer) - and drawing that as a single
> textured quad.

Yes. But I am as bad in drawing images as for modeling.

> > But the capsulation of the Scenegraph the game uses in KobScene will
> > make it possible to 'switch' between different Scenegraphs (at least
> > at compile time).
> 
> OK...but all that abstraction and layering costs time - why do you think

I hope not much, compared to rendering time.

> you need it?   I know it's nice *in theory* to have a choice of scenegraph
> API's but what actual benefit does it bring?   Well, I suppose it lets
> you choose non-portable scene-graphs for specific platforms - but I very
> much doubt that you could reconcile all the little itty-bitty features
> you'll come to need across a wide range of scene graph platforms.
> 
> SSG already acts as a portability layer - why go and build a portability
> layer ON TOP of a portability layer?

Some time I ago I tried to download/compile many 2D-linux games, and
some of them seemed to me to have exactly this feature, to compile
for different bitmap-handling libraries, and I wanted this feature.

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.

> > The aim should be that KobayashiMaru should be able to compile for any
> > Scenegraph and any Soundhandler at any time.
> > I'd really like to use a glDoom/glQuake/Quakeforge/Aftershock-based
> > Scenegraph, if you could give me a pointer to where to find good
> > docu and easy-to-use examples...
> 
> Those tend to be highly oriented to the kinds of game they come from.
> 
> I don't think you could do a good space game using a first-person-perspective
> shooter "game engine".
> 
> I don't know about glDoom or Aftershock - but Quake/Quakeforge are tuned
> for all the fancy flickering torchlight lighting effects and 'portal'
> clipping that being in a dark closed space entails.  That's pretty much
> the opposite of a space game.

Those objections have been already told to me bu a friend, but if you
imagine space as one giant room with no portals, how fast is the
part that renders this? Interesting question for me.

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

> There are also some others that you missed - OpenSG for example.

Bah!

I've checked their Homepage for over three months, it didn't change,
no bits of code. Nothing exept announcements.

> > At the moment I use plibsl for very very basic sound effects, but for
> > a game like that I need full-stereo-full-pitching-xxx-channels etc,
> > even 3D sound will be possible with the right underlying Soundhandler,
> 
> Then I think you should look into 'OpenAL' - which is big-time into
> 3D spatialised sound.

Thanks... will check it.

You also wrote:

> Some corrections:
> 
>  * On 'requirements.html', you say that PLIB is "yet in developer
>    stage".  That's not true.  PLIB is in mainstream use now.
>    Every library gets developed after it's in mainstream use -
>    but you make it sound as though PLIB is still in 'beta' -
>    which it's not.  PLIB 1.2.0 is a 'stable' release.

This was written at the time when plib went in CVS and the loadXXX
functions were written, the appearance of 3ds models changed a
lot on my system. I was referring more to the loading of 3ds
models, I think. I'll correct it.

>  * I think it may be unfair to characterise PLIB as the source

No, it's the _third_ source:
   1. too many polygons due to bad (3ds-converted) models
   2. my own code (I know where I loose time)
   3. plib
   4. but there's no fourth ;-)

>    of your slowness.  You have no proof of that - and to the
>    contrary, there are MANY other games that use PLIB and
>    achieve high frame rates.  So, before you start telling

The problem is that I probably have _imagined_ a higher frame-
rate, and maybe I dream of having better models with a higher
framerate and can't understand why ... sniff.

>    people that my library is SLOW and that you are looking

But maybe it's just so that I think that a game like a Star-
Fighter game will have to be faster and more complex than
a game like Tux.
Actually, I've mo idea.

>    for a faster one - let's see why.  Personally, I accuse
>    all that text you are drawing.  Either way, I resent the

I will time that. And bite my ass if it's true.

>    implication from an utter novice.

I am a novice in 3D maths as well as GL as well as games programming.

If you look at the code, you'll find many really nasty things that
shouldn't clearly be like that, but I have to admit I am a lazy
programmer and tend to write first quick&dirty, and then improve it.
AND there are places in the code were I simply stopped , because
I had problems and wanted to write on another piece of code.

>  * On the math help page you say I'm an amateur - that's not
>    the case - I've been working as a professional 3D programmer
>    for 20 years.  I've designed PC graphics cards - I've written
>    commercial games software - SSG is my third or fourth
>    scene graph API...I forget.

Okay. Ashes on my head. Lot's of ashes. I hope you're non-smoker.

I am just starting to hope that you won't point out too many bad
codelines, please forgive a youngster.

> Some advice:
> 
>   The owners of the StarTrek copyrights are known for vigerously
> chasing people who infringe on their concepts.  Since there is
> a StarTrek book out with the title "#47 The Kobayashi Maru" by
> Julia Ecklar - you might want to think about whether you should
> change the name of your project.
> 
>   Sprinking names like "Borg" around will tend to enhance their
> interest in suing you - even though your game may have nothing
> to do with the StarTrek universe.

See above.

>   These are things that it's easy enough to change - and keeping
> it 'clean' of other people's intellectual property is really
> important for GPL'ed software.

There may come a time when it's necessary to say things like
   sed 's/KobayashiMaru/TuxFleet' `find .`
but I have chosen to wait.

RE: [Plib-devel] KobayashiMaru & plib

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

i peeked at puScrollList.  i just added something very similar to plib.
take a look at the latest plib in CVS...

if you select "SAVE" on the menubar in the examples/src/pui/complex.cxx test
program
it brings up a listbox that might work for you

good luck with your app
--Dave

> I also want to have the plib community to look at ssgUtil.cxx (maybe
> there is something to go to plibsg/plibssg) and at class puScrollList
> I've implemented - puScrollList even doesn't work correct for me,
> but you could take up the Idea and implement a cleanly 
> designed/working
> puScrollList (or is there an easier way?)
> 
> I also have to say that (for my implementation of puScrollList I badly
> need something like puObject->setLegendPlace, in 
> Mission/Model Selection
> the scroll-list in the top-right corner looks like shit - the legends
> should be aligned to the left (inside the widgets).
>
> Alex

Re: [Plib-devel] Blender-specific WRL loader

[Christopher K. S. J. <cs...@qu...>]

> Dave McClurg wrote:
> 
> BTW- is there anyone else actively working on a VRML import for PLIB?  It's a
> beautiful syntax but kind of hard to
> handle the general case (Blender-specific vrml 1.0 isn't bad)
> 

 I wrote part of a VRML97 importer. It was a loader, not a player.
Ran into a couple of problems a) chose to use antlr grammar. antlr
produced, at the time, very ugly and relatively non-portable c++.
b) plib didn't support scaling in transform nodes, and that turned
out to be important for a lot of VRML models. (scaling on load is 
more of a pain than you might suspect) c) lots of interesting
VRML (like HANIM) uses PROTOs, and that's sort of a pain. d) it was
hard to get alpha feedback, and given the amount of work involved,
that made motivation a problem.

 No real show stoppers, but the level of effort required to write
an importer appeared to exceed the global benefit, so I stopped.
A blender VRML 1.0 importer is probably a more useful thing than
a VRML97 importer...

 I might try again later, but maybe not, so you're welcome to
what I've got, just send me an email...


Christopher St. John
cs...@ac...

RE: [Plib-devel] ssgVtxArray fixes.

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

I'll try it ASAP.  I wrote the ssgVtxArray, and use it a lot.  I'm glad
that you found and fixed the problems.  I haven't looked at the code for
some time.

As for index arrays of 'int', that is just ignorance.  If the OpenGL
calls will take arrays of 'short', I see no problem with that change.

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.
> 
> Anyway - could someone who uses ssgVtxArray please try it out 
> and let me know
> if I broke something.
> 
> -- 
> Steve Baker 

[Plib-devel] plib, glut and sdl

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

Hello

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

Thanks Ben

Re: [Plib-devel] Mac Updates/Patches (Tux too!)

[Curtis L. O. <cu...@me...>]

Wolfram Kuss writes:
> While speaking about portable file- and path-functions:
> I would like a function to add two paths. 
> Two examples in Windo$ speak:
> 
> ".\subdir1" plus "subdir2\file.ext" gives
> ".\subdir1\subdir2\file.ext".
> 
> ".\subdir1" plus "c:\file.ext" gives  "c:\file.ext" .
> 
> Is there such a beast in the flightGear code?
> It would be nice if we had something like this in
> the coming plib-functions.

Yikes, from a unix perspective this is un-grokable. :-)

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: ssgContext bug and remedy (was Re: [Plib-devel] Simple SSG examples)

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

Sam Stickland wrote:

> > Do you want CVS write-access to contribute these examples?  If so,
> > I need to know your Sourceforge user ID.
> 
> Yes, that would be good.  It's 'sps196'.  It'll be a day or two before I
> have them all properly commented, and with the full complement of
> makefile though.

OK - you have write access.

-- 
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: ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

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

Sam Stickland wrote:

> Actually it would be nice to be able to provide the bounding sphere
> myself :).   In the case of an explosion if you know the position of the
> fastest moving particle you can calculate the radius of the bounding
> sphere from that.

Hmmm - same as vertices - you can get a pointer to the bsphere:

   sgSphere *ssgEntity::getBSphere() ;
 
...then you can set the center and radius.

   sphere -> setCenter ( x, y, z ) ;
   sphere -> setRadius ( r ) ;

Finally, you have to tell the API that you messed with it:

   ssgEntity::dirtyBSphere () ;

...which will cause all the bounding spheres from there on upwards to
be dirtied and hence recalculated the next time they are rendered.

> You could have a setBoundingSphere method (that would also have to dirty
> all the spheres above it), but then changing an sgTransform would still
> cause the explosions bounding sphere to be recalculated the expensive
> way - perhaps a callback hook for bounding sphere calculations would be
> best?

Well, I think most people would just set the bsphere to the maximum
radius and leave it there.

-- 
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: ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

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

----- Original Message -----
From: Steve Baker <sjb...@ai...>
To: <pli...@li...>
Sent: Sunday, August 06, 2000 8:02 PM
Subject: Re: ssgVtxArrary and ssgSimpleList addtions + pui resize
additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and
texture modes))


> Sam Stickland wrote:
>
> > Well, obviously I should had been using ssgVxtTable rather than the
> > obsolute ssgVTable - which means the set methods I mentioned need to
be
> > a part of ssgSimpleList.
>
> Well, what was intended was that you call ssgVtxTable::getVertex(int
i)
> which delivers a POINTER to the i'th vertex - which you are then at
> liberty to dink with. (Also 'getColour', 'getNormal' and
'getTexCoord')
>
> This is generally faster than a 'get-a-copy-of-the-vertex/dink with
it/setVertex'
> mechanism.

Doh! Yes, that makes sense - I'm too used to thinking of get/set
methologies.  Actually, due to the way I'm converting my explosion class
I was already storing all the positions so I only needed a 'set'
method - it never occured to me to try 'get'.

> One other thing to beware of is that you have to make sure that the
> bounding sphere stays reasonable.  So, either:
>
> * Call recalcBSphere each frame after your leaf node has been messed
with.
>
> * Initialise the object to it's maximum size and call recalcBSphere
just once
>   at start of day.
>
> Which you do depends on your application.  The first is time consuming
because
> recalcBSphere isn't very fast - but it generates accurate spheres
which results
> in less chance of all the polygons being sent to OpenGL when they are
in fact
> off-screen.  The second is faster per-frame but results in wasteful
field-of-view
> culling.
>
> You choose!

Actually it would be nice to be able to provide the bounding sphere
myself :).   In the case of an explosion if you know the position of the
fastest moving particle you can calculate the radius of the bounding
sphere from that.

You could have a setBoundingSphere method (that would also have to dirty
all the spheres above it), but then changing an sgTransform would still
cause the explosions bounding sphere to be recalculated the expensive
way - perhaps a callback hook for bounding sphere calculations would be
best?

> Hence, I don't think we need your change...what we *do* need is better
documentation!
>
> > I've also hacked my copy of pui so that gadget sizes can be
specified in
> > opengl co-ordinates, rather than pixels.  It's very simple - it uses
> > this code from the non-glut part of pui:

[SNIP]

> > If anyone else is interested in this I'll knock up an alteration so
that
> > it can be enabled at runtime.
>
> I guess that's useful - so I'll certainly accept such a patch -
providing
> it doesn't alter the default behavior.

Nope, and it won't take very long at all to do.

Sam

Re: ssgContext bug and remedy (was Re: [Plib-devel] Simple SSG examples)

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

----- Original Message -----
From: Steve Baker <sjb...@ai...>
To: <pli...@li...>
Sent: Sunday, August 06, 2000 7:36 PM
Subject: Re: ssgContext bug and remedy (was Re: [Plib-devel] Simple SSG
examples)


> Sam Stickland wrote:
> >
> > Anyway it works now, so by tomorrow I should have some real simple
ssg
> > examples to contribute.  I've got a simple textured spinning cube,
an
> > explosion, and a simple scene you can fly round (using the
quaternion
> > routines).  Nothing hot, but I always find I learn a damn site
quicker
> > from examples than documentation so I imagine these will be of use
to
> > people.
>
> Great!
>
> Sample programs are always a horrible chore for experts in the API to
> write (we want to build big, complicated programs)...so ironically,
> the best source for example programs may well be in people who have
> just picked up the package and are experimenting with it.

Heh - I do have a bit of an alteria motive here.  If I'm writing sample
programs for plib I might get a bit more help when things don't work
right :)

> Do you want CVS write-access to contribute these examples?  If so,
> I need to know your Sourceforge user ID.

Yes, that would be good.  It's 'sps196'.  It'll be a day or two before I
have them all properly commented, and with the full complement of
makefile though.

Sam

[Plib-devel] ssgVtxArray fixes.

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

I've fixed a small mountain of errors in ssgVtxArray - there seemed to
be one underlying problem...

   ssgVtxArray::getTriangle

...should have been written specially for ssgVtxArray to do the index array
translation to underlying vertex numbers - but was in fact returning entries
into the index array.

Once that's fixed, several of the other functions that had to be written
uniquely for ssgVtxArray can now fall back to the ssgVtxTable implementation.
(There were comments in ssgVtxArray.cxx suggesting that this would be A Good Thing -
and it is!)

So, that's all committed.

Is there some reason why the index array is an array of 'int'?  Since the underlying
SSG classes don't allow more than 32k vertices/normals/colours/texcoords per leaf
node - it seems unlikely that this would be needed - and there are certainly speed
improvements to be had from using a 'short' index array.

Anyway - could someone who uses ssgVtxArray please try it out and let me know
if I broke 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: ssgContext bug and remedy (was Re: [Plib-devel] Simple SSG examples)

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

Steve Baker wrote:
> 
> Sam Stickland wrote:
> >
> > RE: [Plib-devel] Simple SSG examplesThere were a couple of problems with
> > it - one was my fault (polygon winding issues - should had realised back
> > face culling was on by default, doh! ), and the other is a bug in ssg.
> >
> > The ssgContext class initialises the camera matrix to the identity
> > matrix and not _ssgOpenGLAxisSwapMatrix.  So if you do nothing with the
> > camera you end up with opengl's coordinate covention (y is up), rather
> > than ssg's (z is up).
> 
> Hmmm - yes - you are exactly right.
> 
> I have never written a program where the camera wasn't initialised
> explicitly.
> 
> I'll fix it right now.

...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: ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

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

Sam Stickland wrote:
 
> Well, obviously I should had been using ssgVxtTable rather than the
> obsolute ssgVTable - which means the set methods I mentioned need to be
> a part of ssgSimpleList.

Well, what was intended was that you call ssgVtxTable::getVertex(int i)
which delivers a POINTER to the i'th vertex - which you are then at
liberty to dink with. (Also 'getColour', 'getNormal' and 'getTexCoord')

This is generally faster than a 'get-a-copy-of-the-vertex/dink with it/setVertex'
mechanism.

I know this works because PPE uses it.

One other thing to beware of is that you have to make sure that the
bounding sphere stays reasonable.  So, either:

* Call recalcBSphere each frame after your leaf node has been messed with.

* Initialise the object to it's maximum size and call recalcBSphere just once
  at start of day.

Which you do depends on your application.  The first is time consuming because
recalcBSphere isn't very fast - but it generates accurate spheres which results
in less chance of all the polygons being sent to OpenGL when they are in fact
off-screen.  The second is faster per-frame but results in wasteful field-of-view
culling.

You choose!

Hence, I don't think we need your change...what we *do* need is better documentation!

> I've also hacked my copy of pui so that gadget sizes can be specified in
> opengl co-ordinates, rather than pixels.  It's very simple - it uses
> this code from the non-glut part of pui:
> 
> static int puWindowWidth  = 400 ;
> static int puWindowHeight = 400 ;
> 
> int puGetWindowHeight () { return puWindowHeight ; }
> int puGetWindowWidth  () { return puWindowWidth  ; }
> 
> void puSetWindowSize ( int width, int height )
> {
>   puWindowWidth  = width  ;
>   puWindowHeight = height ;
> }
> 
> I need this because I use some of the pui gadgets (well actually
> subclasses of the pui gadgets), to add controls to my HUD (this is also
> coupled with calling  puGetUltimateLiveInterface () -> draw ( 0, 0 ) ;
> myself rather than calling puDisplay() - as this would cause a redundant
> glViewport call).
> 
> If anyone else is interested in this I'll knock up an alteration so that
> it can be enabled at runtime.

I guess that's useful - so I'll certainly accept such a patch - providing
it doesn't alter the default behavior.

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