Jump to content
  • Advertisement
Sign in to follow this  
l0calh05t

Difference between non-power-of two and rectangular textures

This topic is 3863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, what is the real difference between non-power-of-two and rectangular textures? Only that rectangular textures use non-normalized texture coordinates (which doesn't seem particularly useful)? And where would one be used instead of the other? I'm asking because I am currently using non-power-of-two textures for my screen-size offscreen buffers, and I'm wondering why everyone seems to be using rectangular textures instead.

Share this post


Link to post
Share on other sites
Advertisement
I think Geforce FX series doesn't support NPOT at all so you have to use RECT.
Radeon 9500 and up, Geforce 6100 and up support both but with various abilities.
For example, Radeon 9500 does not do mipmaps, border texels, you have to use CLAMP_TO_EDGE.

In principle, with GL 2.0, you are suppose to have full support for NPOT, including support for 3D and cubemap.

Sounds like you can use NPOT for your needs.

Share this post


Link to post
Share on other sites
RECT textures don't use normalized coordinates and there are no border texels and mipmaps with them. They are supported on older hardware before NPOT textues were introduced.

NPOT texutes require normalized texture coordinates and the specification also requires mipmaps for these textures. Some hardware might not fully support this texture type in hardware even though it reports to support GL 2.0. This is the case for my Radeon X800 XT which only supports NPOT textures with some limitations, namely no mipmaps, no border texels, CLAMP_TO_EDGE.

Share this post


Link to post
Share on other sites
So for backwards compatibility Rectangular textures would be reccomended? Considering that I need no borders, no wrapping and probably also no mipmaps (except perhaps for quicker blurring...) I might switch to rectangular textures. OTOH, what I'm currently writing will probably not run correctly on anything older than Geforce 7300 (My current card is a Geforce 8600M), so it's probably a waste of time...

Share this post


Link to post
Share on other sites
Quote:
Original post by l0calh05t
So for backwards compatibility Rectangular textures would be reccomended?
Yes, it's the only good reason to use them but unluckly, it's a very important reason.

Share this post


Link to post
Share on other sites
In light of the fact that a very, very basic test (a sphere, a box, 3 directional lights) only ran at ~20fps on a friends laptop with geforce 7600 go. I see the importance of that reason fading quickly... but it should be only ~10 lines of code to change, so.. why not?

Share this post


Link to post
Share on other sites
20FPS is way too slow.
I think you need to update drivers or something. What do you get with power of 2 texture?

Share this post


Link to post
Share on other sites
Uh, that was on a friend's computer. And yeah 20 fps *is* slow, but I think it may be because of slow video memory. On my geforce 8600M I got ~130fps at a much higher resolution. (And *my* drivers aren't exactly new, dell doesn't update their drivers particularly often)

Share this post


Link to post
Share on other sites
Quote:
Original post by l0calh05t
...with geforce 7600 go. I see the importance of that reason fading quickly...
Believe it or not, 7600 is still to be considered pretty high-end. Especially for people with ATi, full NPOTD cannot be assumed to be widespread. Alot of people is still running PS2.0 hardware an this tipically employs RECT. I wouldn't say dropping RECT is a good idea for now, unless you run exclusively on last-gen ATi or sort-of-common NV.
Quote:
Original post by l0calh05t
but it should be only ~10 lines of code to change, so.. why not?
Unluckly, it doesn't just take to change the binding token. You must also scale TexCoords accordingly (just say you late-bind textures and you get the idea), prepare to have two code paths, change your shader source if you use shaders, get ready for another texture target priority if you don't... it may be about 10 lines for the techdemos on the net but complex apps will show an additional inherent level of complexity.

RECT is a real pain to support, especially if you let your users do their content AND you want them to be shader-enabled. Its use is pratically limited to managing your framebuffers. I would have dropped it the same day ARB_npot were annunced. I wish you the time has come to simply assume ARB_npot: it's much easier and way more orthogonal but I fear this to be still too much.


Share this post


Link to post
Share on other sites
Hm... since I don't really use anything RECT textures don't provide (I only use the NPOT textures for Framebuffers, I was planning on sticking to normal pow2 textures for pretty much everything else), wouldn't it suffice to simply switch to them (instead of NPOT)? In that case multiple codepaths would not be needed. (Although that is assuming that cards supporting NPOT textures *continue* to support RECT textures...)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!