[GEM] update && Re: [PD-dev] [GEM] update

zmoelnig at iem.at zmoelnig at iem.at
Wed May 14 22:52:39 CEST 2003


hi. 
i just wrote an answer, then the phone-jack plugged itself out of my modem-
connector, and it was gone.
i hope i can recall everything.

Zitiere chris clepper <cclepper at artic.edu>:
> >hi all.
> >
> >just commited one or two changes to the cvs.
> >1. Pixes/pix_texture now has automatic yuv2rgb conversion (on 
> >non-mac's -- i couldn't get my nvidia to texture yuv422-maps 
> >correctly)
> 
> that's too bad.  without being able to upload the yuv texture a fair 
> amount of the speed gain is lost.

which is true, but it should have been read: "i couldn't yet get my nvidia to 
texture yuv422-maps" (note the *yet*)
and i haven't yet found any(!) documentation.
however, there is the speed gain that comes from the mere smaller amount of 
data.
and at least, all the yuv things do work at least without too much hazzle.

> 
> it sort of defeats the purpose of runtime checking if you have to add 
> compiler -D options to get it to work for each check.  that's why 
> that code is in there.  would a solution be to disable runtime checks 
> on Windows and Linux?   on linux you can check for this in the 
> configure script but I don't know how you would get around this for 
> binaries on Windows (apart from having multiple versions for each 
> vendor, ugh).  surely the game developers get around this because if 
> MS only uses GL 1.1 then there would be no point in developing games 
> like Unreal or Doom  or high-end modelling apps on Windows.

i think you hae got something wrong.
it's simple: differentiate between compilation time and runtime.
compilation-time: all the defines i am using for the ifdefs merely come from the
GL/gl.h-headers, so there is no need for "-D" flags.
i just cannot use "glEnable(GL_TEXTURE_RECTANGLE_NVX)" if i do not have the 
nvidia-openGL-headers installed. so i have to ifdef it (and i think it is very 
sophisticated to ifdef it with GL_TEXTURE_RECTANGLE_NVX)
run-time: checks for openGL-extensions work very well under linux (and i guess 
under windows too, otherwise the whole openGL-standard would be pointless in 
redmont). but unfortunately i can (successfully) check for extensions at 
runtime, although they have not been present during compilation.
for instance, if i do not use the nvidia-openGL-headers, a check for 
GL_NV_texture_rectangle (or whatever it is called, cannot remember now exactly) 
will still return "1" if you are using a recent nvidia-driver.
but then GemMan::rectangle_supported is true, which will lead to execution of 
some code (in pix_texture) that is plainly producing unwanted results, like 
black textures.
so one solution would be to check for the extension *and* #ifdef all the 
rectangle-code in pix_texture.
the other one (which is easier to add later and easier to read anytime (because 
#ifdef's are not really code-reader-friendly) is to check only for a certain 
extension if the feature is supported at compilation time.
that's why i have #ifdef'ed some parts in GemMan.cpp

furthermore: please do not remove #ifdef's if they do not break anything.
if they do, please add some comment in the code why you don't want it there.

generally i don't like prepocessor-defines and only add them, if i need it to 
compile.

> 
> >3. Copied yuv/[yuv_emboss] to Pixes/[pix_emboss] (to have one true 
> >yuv-effect for testing)
> >however, that was what i meant in one of my previous mails: yuv2pix 
> >is not yet finished since there are a lot of yuv-effects...
> 
> why yuv_emboss?  it doesn't really work so well if i recall...;) 

yes, i noticed, that it did something i didn't really expect...

> >How do you handle installation ?
> that's the tricky part.  i would like to have an installer script for 
> OSX too, which could be done via unix script or AppleScript.
maybe unix-shell-scripts would be better, because it's more multi-platform and 
it could be shared across the various un*xes. 
but then under linux the thing is either handled by "make install" or the 
package-manager (which refers to "make install"


> 
> i guess it's ok to have those calls in filmNEW, they just require 
> ifdefs to keep things straight.  i put an ifdef in pix_filmNEW since 
> i'm not compiling the non-OSX classes.

all the classes should well compile under all OS's (although the preprocesser 
would maybe strip them to the plain dummy class film (whích wouldn't be able to 
load anything)
but it is true that i haven't quite done it that way, but made lot's of 
#ifdef's around the lib-dependent code.

mfg.as.rd
IOhannes




More information about the Pd-dev mailing list