Oh and thanks for the texcoord code, didn''t realize it would be as simple as that. I guess I thought the S and T coords worked for one set of equations only.

quote:
It has to convert all of them, including float, since it internally operates on a fixed point format

Not that I don''t believe you, but I''d really like some second opinions before I''ll completely accept that. Do you happen to have any links to documents backing up that assertion?

Well, Cass Everitt mentioned it a few times on openg.org, on a discussion about precision problems of large floating point numbers. So, if an nVidia engineer says so, I guess it must be true Don''t have a direct link, sorry.

What I know for sure, is that there is no additoinal conversion cost associated with different input data. Float is actually the slowest in terms of memory footprint (more cache misses), but it''s better supported by the driver (see ''optimized'' vertex formats), because it is so widely used. If you bypass the driver by directly VARing into the GPU, you can actually see that the speed is directly related to the size of the format: short is fastest, float slowest.

Other thing I know for sure, is that NV10 (and NV20 also, I think) use a 9 bit fixed point format after the transform stage (in the fragment pipeline). I''m not sure about the size of the initial format, they don''t really tell you those details, since it''s considered as trade secret.

/ Yann