[PD-dev] ? about GEM #ifdef's

[Daniel Heckenberg]

? about GEM #ifdef'sThose symbols are defined in gl.h I believe.  I imagine
that the GL_VERSION_1_1 should be defined for 1.1 and higher.

Yeah, there are a few fairly hairy tracts of code where ifdef blocks are
used to implement certain features with a variety of techniques according to
the openGL version and extensions available.  I don't think that anyone is
going to be using OpenGL < 1.1 anymore (am I wrong?),  so many of these
blocks are going to be pretty redundant (and possibly untested for some
years).

It would certainly be nice to clean this up... and implementing an OS
independent runtime extension check (and openGL version checking mechanism?)
would be a nice addition too to allow binaries to be built which can run on
a range of hardware (and deal with Windows' "different" way of handling
extensions).

daniel
  -----Original Message-----
  From: pd-dev-admin at iem.kug.ac.at [mailto:pd-dev-admin at iem.kug.ac.at]On
Behalf Of tigital
  Sent: Monday, 9 September 2002 9:26 AM
  To: pd-dev at iem.kug.ac.at
  Subject: [PD-dev] ? about GEM #ifdef's


  hiya,


  ...well, on OS X, I finally think I've got a better way of opening movies
(and therefore everything else) that does without the copy from offscreen
buffer to image.data...however, it did make me wonder what a coupla #ifdef's
are, or at least their purpose:


  #ifdef GL_VERSION_1_1
  ...and...
  #elif GL_EXT_texture_object


  ...I know that OS X supports GL_Version 1.3 in hardware and 1.1 in
software (at least on my Radeon mobility), but I don't see a GL extension
for GL_EXT_texture_object...is this some kind of legacy extension?


  Also, is the #ifdef GL_VERSION_1_1 valid for version 1.1 and higher?


  I'm quickly coming to an understanding that I need to acquaint myself with
the "red book" a bit more, cuz I just spent the last week trying figure out
why textures came out weird, and it turns out to just be a need for
GL_UNSIGNED_INT_8_8_8_8_REV instead of GL_UNSIGNED_BYTE...at least as far as
GL_RGBA goes!


  Lastly, maybe it would be a good idea to central-ly locate and explain all
of the existent "#ifdef's" in a readme file, so there'd be less confusion
for new contributors...


  l8r,
  jamie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20020909/96c2bbd0/attachment.htm>