[osg-submissions] EXT_texture_integer submission ShaderModel 4.0
Art Tevs
stud_info2 at yahoo.de
Fri Sep 7 06:40:26 PDT 2007
Hi Robert,
I know that void* is not the solution. This was just a
suggestion. Also using of union might help but it
sounds like a hack.
I have running some tests with type conversion on
signed and unsigned integers with float and doubles:
for (int i=-INT_MAX; i < INT_MAX; i++)
{
double c = (double)i;
int k = (int)c;
if (k != i) printf("i=%d, k=%d, c=%f\n", i, k, c);
}
If you disable compiler optimization, then you can see
that using of floats produce incorrect results.
However doubles seems to work fine on my machine (AMD
Opteron 2218). I am not sure if this test works also
fine on pure 32bit CPUs, but it seems that doubles
could be the candidate for the border color.
But however there still the question about
intuitivity. Setting a 32 bit string and converting it
first to double to be able to pass the setBorderColor
method is not the right way. But however for now I can
live with it, since I do not work on things which
require precise border definition ;-)
To the enums: The enums were just thought as internal
flag to find out if the texture is of integer type or
not (e.g. to be able to pass right border color).
However if you like to implement some new methods like
isFloatTexture() isIntegerTexture()
isUnsignedIntegerTexture() and isNormalizedTexture()
then I would agree with that. The detection can either
be done before or on the fly by looking at the
texture's internal format.
Submission:
Ok I will make the corrections with the border color
we have spoken about. I am now waiting on your
decision about the integer/float flags/enums and how
do you think to handle them. I will then change my
submission and post it again.
Art
> HI Art,
>
> I have several concerns that I have grapple with
> when see new features added
>
> 1) They fit in well with existing codes
> 2) They avoid breaking API unless really
> necceassary.
> 3) The minimal and complete rule applies
> 4) The addition doesn't introduce undue complexity
> into the interface or
> implementation.
>
> You suggest for having multiple border color types
> or void* fails on
> several counts and I won't be merging anything like
> this.
>
> The least intrusive solution I can see it to go the
> Vec4d route as
> case where required. Doubles casting to ints should
> work without
> precision loss until you get to reasonable large
> numbers. It might
> not be a perfect implementation for pure int texture
> formats but its
> certainly far less intrusive and confusing than
> duplicating variables
> and methods or using void*.
>
> As for enums, I would suggest that the feature is
> generally more
> information than just being something specific to
> the new int texture
> extensions, we really have to avoid the enums being
> too cryptic too -
> others have to use and maintain the code, the less
> obvious it is the
> more mistakes will be made and the more bugs we'll
> have.
>
> Robert.
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
>
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
__________________________________
Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever
More information about the osg-submissions
mailing list