Re: [Plib-users] Hi all!

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

Cameron Blackwood wrote:
>   | > was a little puzzled not to find that  puFileSelector  didnt just
>   | > use a base class like  puEditableChunkOfLineSelector  or something. ;)
>   | 
>   | It's a valid thought.  I guess we all just wanted a file selector
>   | widget and didn't think too much about more general applicability.
> 
> It only stuck me, because reading the docs, I was expecting it from the
> (excellent) modular design.....
> 
> ... that combined with the fact that Id just come from the Utility
> Library docs and that had me thinking about those 'virtual file
> systems' routines in 'doom' type games where it ties a whole lot
> of zip files together into one FS. (Not that im in any way supporting
> that as an idea. ;)

Yeah - exactly.  It's not an unreasonable request.

> clueless questions
> ==================
> minor
> -----
> http://plib.sourceforge.net/pw/index.html uses pwCallbacks
> but my installed version  media-libs/plib-1.8.4 uses pwSetCallbacks

Oops - typo.

> pwSwapBuffers and vsync
> -----------------------
> The book (and the man page) refers to flipping buffers in GLX waiting
> for the vsync, but pwSwapBuffers doesnt seem to do this (which is what
> I prefer :). But if thats the case, do I use the raw glFlush if I want
> to wait?

Unfortunately, neither OpenGL nor GLX nor X gives you control over how
swapbuffers does or does not tie into vertical sync.  Each graphics card
appears to use a different mechanism.  With nVidia, there is a shell
variable under Linux and some kind of a control panel thingy (which probably
does registry hacks or something) under Windows.  Dunno what MacOS does.
Under IRIX, locking to vsync is enforced at all times and under Solaris,
it's just not possible at all.

glFlush won't enforce a wait either.  All it does is ensure that the
device driver has sent everything off to the hardware.  There is an
implicit glFlush associated with swapbuffers anyway because the hardware
can't swap the buffers until everything has finished rendering.

> I guess I dont need to worry about flickering if Im double buffered.
> And I guess I could put in a sleep if I dont need the cpu...

Double-buffering will stop flicker either with or without syncing to
the vblank - but without that synchronisation, you'll get tearing of
the image (most noticably when panning at high speed).

You can't do anything in the CPU to help that either because (in general)
the CPU doesn't know when the vertical blank is coming either.

Doing a usleep in the CPU is justified in many cases in order to ensure
that the application doesn't try to render at hundreds of hertz frame
rates and eat all of your CPU time.

> multi windows?
> --------------
> Im an opengl newbie so im working my way through "OpenGL programming
> guide" and I noticed that plib supports more than one window. But I
> havnt worked out how set which one to draw to given that pwInit doesnt
> return anything (not that Im going to use that, but I thought it was
> best to comment on this stuff as I hit it).

PLIB comes with it's own windowing library 'PW' - and PW does NOT support
multiple windows because it's aiming to be very, very simple and most games
and other similar interactive 3D applications tend not to need multiple
windows.

However, you don't have to use PW - you could use SDL or GLUT or FLTK or
raw Xlib or GTK or...pretty much any other windowing library.  If you pick
one that can do multiple windows - then the remainder of PLIB (excluding PW)
will support that.

PLIB is a kit of tools - and generally speaking, you can use just some of
the tools without being wedded to using the whole set to the exclusion of
all others.

> returning vectors
> -----------------
> I was looking at sgSphere and I noticed:
>   sgVec3  center ;
>   SGfloat *getCenter (void) ;
> 
> not:
>   sgVec3  *getCenter (void) ;
> 
> Which made me wonder if it was the same structure or one that had
> 'munged' into an array of 3 SGfloat (which further looking at the code
> shows that that was was an sgVec3 was). I guess its just so that it
> can return 2, 3 or 4 element coords.

sgVec's are just one dimensional arrays of floats.  They are just typedef's.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----