2

I am just about to release a wallpaper app that's going to use user's own images... which may be non power of 2 size. Textures of all size seems to be supported on my Nexus 2013 tab and Moto X 2013 in Open GL ES 1.1.

My question is:

  1. Does the OpenGL ES 1.1 have power or two limitation in some devices/android versions?
  2. If there is a limitation, can I over-ride it somehow to choose textures of any size?
hata
  • 11,633
  • 6
  • 46
  • 69

3 Answers3

1

Does the OpenGL ES 1.1 have power or two limitation in some devices/android versions?

NO ES 1.x does not support non pow 2 textures, it started supporting it in ES 2

If there is a limitation, can I over-ride it somehow to choose textures of any size

either change your Opengl profile to ES 2 if you can't then you have to convert your texture to a pow of 2 one

EDIT

there is some kind of workaround maybe to try out see here

Community
  • 1
  • 1
unique_ptr
  • 586
  • 1
  • 8
  • 22
  • Perfect responses and there's absolutely nothing more for me to ask! –  Aug 12 '15 at 18:41
1

OpenGL ES 1.1 does not support non power of two textures. There are extensions like GL_OES_texture_npot that add the support, but possibly with limitations to texture wrapping. OpenGL ES 2.0 does support npot textures, but still only with GL_CLAMP_TO_EDGE wrapping, so texture repeating might not work with npot textures.

Usually best option to avoid texture size restrictions is to use a texture atlas i.e. a large power of two texture that contains multiple non power of two textures inside.

EDIT:

Here are couple of examples of reports of devices not working with non power of two textures: Galaxy Player, Ouya.

Here is a list of some devices' GL extensions. The ones without GL_OES_texture_npot or GL_ARB_texture_non_power_of_two extensions should not work with non power of two textures.

An alternative to texture atlases is to pad the texture with black to the nearest power of two dimensions, but it will waste texture memory. You can store your textures in non power of two dimensions and do the padding programmatically.

Community
  • 1
  • 1
JanneK
  • 892
  • 9
  • 9
1

I would not rely on support for NPOT textures, even with OpenGL-ES 2.0. Power of two texture, even if they aren't mandatory, are always better for performance reasons.

To overcome this issue, try using texture coordinates correctly. For example:

Let's say your original image is 300x500. The closest Po2 size for this texture is 512x512. We take the original 300x500 bitmap, and paint it on a 512x512 bitmap and create a texture from that. We don't scale when we create the larger bitmap, so the larger bitmap will appear to have blank edges on the right and bottom.

Normally, your texture coordinates (for a flat square model) would look something like this:

float[] textureCoords = new float[] {
    0, 0,
    1, 0,
    1, 1,
    0, 1
};

The 0 in each coordinate indicates the "beginning" edge of your texture, whereas the 1 in each coordinate indicates the "end" edge of your texture.

Now we want to "trick" the system to not render the whole texture, since any pixel greater than 300 horizontally or 500 vertically is blank. So, instead of using "1" as the end value, we use the ratio of the two images: 

float w = 300f / 512f;
float h = 500f / 512f;

float[] textureCoords = new float[] {
    0, 0,
    w, 0,
    w, h,
    0, h
};

With these texture coordinates, only the relevant part of the texture will be drawn.

As JanneK pointed out, you can use this method to create 1 large texture which contains all the other textures you need, and then use texture coordinate mapping to only extract the parts you want from that texture. This will allow you to optimise your textures rather than just waste that "empty space" in the PO2 texture.

Hope this helps.

Community
  • 1
  • 1
Gil Moshayof
  • 16,633
  • 4
  • 47
  • 58
  • Do you have data showing that POT textures are faster on any even moderately recent hardware? – Reto Koradi Aug 13 '15 at 05:30
  • I'll elaborate - staying in POT is generally safer, and can avoid unintended behaviour, and needless computation, thus improving performance. The problem arises from mipmap computation, which for every level, reduces the size of the previous level by half for each dimension. With POT textures, this is easy, but with NPOT textures, this requires an additional computation. GL_LINEAR_MIPMAP_NEAREST has low computation, but results can be bad, GL_LINEAR_MIPMAP_NLINEAR performs an average tests which costs computation time. Reference: https://www.opengl.org/wiki/NPOT_Texture – Gil Moshayof Aug 20 '15 at 12:23