I''m curious ... does anyone know why OpenGL requires that all textures be square and have a dimension that is a power of 2? I''ve managed to work around it, but it is a bit of a pain in the a$$. I just wonder why this is the case. -Eric

They don''t have to be square. They just have to be power-of-2. Probably becouse fast memmory acceess (you can get memory address using just bitshifts). But, there are extension that let you use non-power-of-2 textures.

You should never let your fears become the boundaries of your dreams.

Yes, if you''ve ever written a software rasterizing engine, shifting is much simpler than multiplication, and in hardware, it''s a lot less circuitry, which means smaller die sizes, less heat, which means increased clocks . Honestly, with all the stuff they have in the graphics core already, i''m sure dividing wouldn''t kill anything, which/could easily allow for non power of 2 textures, and I beleive some of the graphics boards do, or will start, using supporting this, but due to backwards compatibility, you still should use powers of 2 (or just use mip-mapping, which automagically takes any size texture and makes it a power of 2).

mipmapping itself doesn''t help. its just the gluMipmap function that is a utility function that does it for you.. gluScaleImage (or how ever called) can do the same for nonmipmapped textures..


and opengl1.5 introduced ARB_non_power_of_2, and all geforces and radeons i know of (check delphi3d for exact reports) eighter support GL_NV_texture_rectangle or GL_EXT_texture_rectangle (both are EXACTLY the same, just a different name in the extension string).

---

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

absolutely not!

check the specs (taken from ARB_texture_non_power_of_two)

5. How is a conventional NPOT target different from the texture rectangle
target?

STATUS: RESOLVED

RESOLUTION:
The biggest practical difference is that coventional targets use
normalized texture coordinates (ie, [0..1]) while the texture
rectangle target uses unnormalized (ie, [0..w]x[0..h]) texture
coordinates.

Differences include:

+ In ARB_texture_non_power_of_two:
* mipmapping is allowed, default filter remains unchanged.
* all wrap modes are allowed, default wrap mode remains unchanged.
* borders are supported.
* paletted textures are not unsupported.
* texture coordinates are addressed parametrically [0..1],[0..1]
+ In EXT_texture_rectangle:
* mipmapping is not allowed, default filter is changed to LINEAR.
* only CLAMP* wrap modes are allowed, default is CLAMP_TO_EDGE.
* borders are not supported.
* paletted textures are unsupported.
* texture coordinates are addressed non-parametrically [0..w],[0..h].