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