[GEM-dev] pix_texture

[zmoelnig at iem.at]

Zitiere Daniel Heckenberg <daniel at bogusfront.org>:

> 
> Hi All,
> 

hi all.

> I would certainly hope that we can avoid both #ifdef NIGHTMARES and
ahyes, the
#if 1 / #if 0
nightmares certainly are mine.
i'll try to remove them.

> splitting the code object by object on platform lines.  Both of these
> approaches are hard to manage in the long run.
> 
> If we can characterise the different behaviours of each platform and
> make
> the code behave accordingly at run-time that would be great.  One
> example
> that comes to mind at the moment is the vertical flip required for
> quicktime
> images.  That's not so much a platform issue as a behaviour (QT for
> Windows
> and DirectShow (sometimes) return "upside down" images).  Writing
> completely
> separate OS-dependent classes won't help in that situation.
and the problem continues with rectangle-textures.
i was thinking about making an additional "texCoordHint"-structure, that will
set the basic texture-coordinates (upside-down + un/normalized textures) by the
image-source.
[pix_texture] and [pix_coordinate] would then just have to define a
relative-coordinate (multiplication factors)

> It's a similar situation with extension support I guess...
and i don't see any solution without ifdef'ing for references like
GL_TEXTURE_RECTANGLE (or whatever it is called exactly), that are simply not
defined in several header-files.
(yes classes would move the ifdefs somewhere out of the procedures into
head/foot of the files)
and with [pix_texture]: there are a lot of critical #ifdef's that support
openGL<1.2 (to me it even seems like some pre-version (<1.0) of openGL is
supported ;-)) this could surely be wrapped into classes more elegant

btw: the long-discussed "new" animated-images sources (film*...) came into
beeing just because i wanted to get rid of a lot of #ifdef's.

but really i do think we should do a (boring) feature-freeze and release.
but of course, that's is dull work.


mfg.asd.r
IOhannes