gem-0.84 again

[umläute]

Me wrote:
> > now, would you mind to do a help patch for the "pix_snapshot" too :: i
> > just cannot get it snap anything (i guess it should make a snapshot of
> > the current GEM-Window from lower left to upper right corner ?)

Mark Danks wrote:
> 
>   With pix_snapshot, that is basically it.  Make sure that you are snapping
> a power of two if you want to texture map with it...
> 

ha, i know: if i do not choose a size a power of 2 the texturing will
not take place at all (due to the bad sized picture that cannot be
textured by openGL itself); if i do choose a pix the size a power of two
(e.g. 256x256, 16x16...) the texture evidently takes place;
unfortunately i grep very dim (this should really read :: black)
pictures all the time, so i would be easier to not snapshot at all (i
think i have some black pictures anywhere at home);
so what do i have to do to snap anything "cool" or at least anything BUT
black ?

ah, maybe the GL(U(?))_SNAPSHOT is not really supported by my driver
(native NVIDIA-0.9_3)
i got the NVIDIA-openGL-developer package today (that consists mainly of
the GL-headers); up till now i could not compile GEM on my machine since
the nvidia-drivers conflict extremely with everything with the odeur of
mesa and so i didn't install the mesa-dev-package. What i used up till
today was a mesa-compiled GEM; i have now compiled it with the "real"
headers, and indeed, Gem looks far more stable (especially when
destroying the Gem-window-context; this led to crashes on the old hybrid
mesa/open-GL GEM is used

on the other hand there appeared a strange behaviour when trying to
compile objects that make use of the GLenum type;
everytime the GLenum appears in the gem-code it is together with a
cast:: par.example " m_drawtype = (enum GLenum) GL_FILL "
i had to replace the (enum GLenum) cast by a (GLenum) cast and
everything worked fine
i think this is a true linux problem and i wonder whether it's a mere
mesaGL problem; as far as i remember, this cast is really part of the
linux-port by guenter; when i first compiled my Win32-programmed Geos
(like the mythical "disk") which lacked of such casts because it works
fine this way uner Win, under linux, i got severe problems; doing the
mentioned cast solved these; now it seems that the nvidiaGL resembles
more the winGL than the mesa one ???


mfg.df.ar
iohannes