Hmm, the last time I posted a message in reply to a request for an ARB extension for vendor-specific functionality (in that case, VAR/VAO), Cass announced VBO that day. Let’s see if it works again.
Consider that VAR is older than NV_texture_rectangle. Not only is it older, it is much more useful. And yet, it took the ARB a good 2 years to come up with VBO. Give them time. Yes, by all rights, this should have already been done. But they’ll get around to it eventually.
If there is to be an ARB version, one improvement it could have would be to accept texture coordinates in the standard [0,1]x[0,1] range. There may be a reason (if so, let me know), but I can’t see why texture coords need to be specified in [0, w]x[0, h].
Surely the driver could do the conversion between the 2, maybe by using the texture matrix? The driver certainly knows the size of the texture.
"NV_texture_rectangle
Supports non-power-of-2 sized textures. Restrictions in NV spec: cannot be mipmapped, cannot be wrapped, no borders, texcoords go [0…width,0…height] instead of [0,1] to allow accessing specific texels. Uses a separate texture target (instead of TEXTURE_2D) because of these restrictions.
Bimal is interested in the functionality but unsure about extended range texcoords, especially if mipmapping is possible. It’s apparent that this isn’t ready for core status due to several open issues.
Jeremy will lead a small working group to fix up the spec. Jon will create the WG mailing list. Noted that Apple is shipping EXT_texture_rectangle, which is similar to the NV version but relaxes some of the restrictions; Jon would like a copy of the EXT spec for the registry."
BTW: NV_texture_rectangle and EXT_texture_rectangle use the same defines so it’s actually easy to support both with a single code path even though NVidia only exposes NV_texture_rectangle in thier drivers.
Just becourse they started out with extended texturecoord range doesnt mean that it is a good idea
I hope that the final spec will have 0 to 1 instead… this makes the fallback routines much simpler, and as stated from the ARB meeting, what about when Mipmaps are supported, then the extended value doenst pick a specific pixel anyway, and i guess thats the only argument for the extended coords they have right now.