It would be nice to have an ARB or EXT version of rectangle textures.
It’s been a very long time NVidia has their own extension but why hasn’t an ARB version been made available?
Sorry if this was suggested already, but we have GL 1.4 now and still no ARB/EXT version.
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.
Yes, the texture coordinates thing is pretty odd, but since that’s the way it started, better continue like that.
Im just using this extension as a render to texture, and then render back to framebuffer as a quad with texture.
There is even a NV_render_texture_rectangle just for this in case anyones interested.
Thank you VBO! That was very much needed.
From the March ARB meeting notes:
"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."
The Apple specification http://developer.apple.com/opengl/extensions/ext_texture_rectangle.html
Supported on ATI hardware but strangely not on NVidia http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_texture_rectangle
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.
TEXTURE_RECTANGLE_EXT 0x84F5
TEXTURE_BINDING_RECTANGLE_EXT 0x84F6
PROXY_TEXTURE_RECTANGLE_EXT 0x84F7
MAX_RECTANGLE_TEXTURE_SIZE_EXT 0x84F8
TEXTURE_RECTANGLE_NV 0x84F5
TEXTURE_BINDING_RECTANGLE_NV 0x84F6
PROXY_TEXTURE_RECTANGLE_NV 0x84F7
MAX_RECTANGLE_TEXTURE_SIZE_NV 0x84F8
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.