glCompressedTexImage2D: negative value for level parameter?

Apprentice
Posts: 10
Joined: 2008.11
Post: #1
Has anyone tried submitting a complete mipmap stack generated by texturetool to glCompressedTexImage2D? According to the OpenGL ES specs level must be <= 0, specifying the number of mipmaps described by the submitted buffer.

Unfortunately I've failed to generate a valid texture so far. Compressed textures seem to improve performance quite a bit (less cache misses?), so I'm thinking that a complete compressed mipmap stack may be the fastest possible rendering configuration.
Quote this message in a reply
Sage
Posts: 1,234
Joined: 2002.10
Post: #2
That man page is wrong. It's written for ES 1.0, where the only compressed formats were paletted.

See the real documentation where the level argument to CompressedTexImage is defined to work just like TexImage. I.e. it is >= 0 for each individual level you provide, not negative.

The negative level thing is from this terrible spec which is supported on the phone, but is completely useless. The negative parameter means all levels are provided at once in a single blob, but it is only valid for paletted formats.
Quote this message in a reply
Member
Posts: 45
Joined: 2008.04
Post: #3
<= 0, how odd... I've been doing it standard opengl style by submitted the data (from texturetool) by looping through the 0..N mip-levels and submitting each plane via glCompressedTexImage2D() - works fine

meh... too slow in writing my reply ;-)
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2008.11
Post: #4
Ah I see, thanks.

aBabyRabbit make sure you verify your mipmap stack is valid, I'm getting a lot of INVALID_VALUEs right now (still looking into it) but the textures look fine because level 0 is specified correctly. My guess is that mipmapping doesn't really work though. Unfortunately specifying red/blue/green mipmaps levels for verification doesn't work with compressed textures.
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2008.11
Post: #5
Ah yes ...

Quote:WARNING: Valid PVRTC data is at least 32 bytes in size. This means that images that are less than 8x8 (at 4bpp) or 16x8 (at 2bpp) will be padded to 32 bytes total before being written to the archive. For example, compressing a 4x4 image consumes 32 bytes, even though it only requires 8 bytes of storage. If you are using the mipmap option with Raw data files, ensure that you take this into consideration as you are reading them.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Can I load OGL_RGB_888, OGL_RGB_555 PVRs with glCompressedTexImage2D on iPhone? riruilo 6 5,926 Oct 22, 2009 02:38 AM
Last Post: riruilo