----- Original Message -----
These limitations are only when you're rendering to an FBO with a
renderbuffer as the color attachment. If you have an RGBA texture as
the color attachment you ought to be able to portably get 8 bits per
channel. (I think...)
You know, I've gone back and forth on this.. section 4.4.5 in the ES 2.0 spec (2.0.24) is unclear. It states:
The internal formats of the attached images can affect the completeness of
the framebuffer, so it is useful to ﬁrst deﬁne the relationship between the internal
format of an image and the attachment points to which it can be attached. Image
internal formats are summarized in table 4.5. Color-renderable formats contain
red, green, blue, and possibly alpha components; depth-renderable formats contain
depth components; and stencil-renderable formats contain stencil components.
Formats not listed in table 4.5, including compressed internal formats. are not
color-, depth-, or stencil-renderable, no matter which components they contain.
Note the usage of the generic "attached images" -- no distinction between a renderbuffer and a texture. However, the caption for table 4.5 states "Renderbuffer image formats, showing their renderable type ...", explicitly stating Renderbuffer.
But then later on in section 4.4 at the start of page 117:
Although OpenGL ES deﬁnes a wide variety of internal formats for
framebuffer-attachable images, such as texture images and renderbuffer images,
some implementations may not support rendering to particular combinations of
and states that checking framebuffer completeness is required. This seems in direct conflict with the statement that the formats not listed in 4.5 are not renderable, unless the intent was to say "nothing outside of table 4.5 is renderable, but formats in 4.5 /may/ be renderable", which seems wrong.
Is this confusing to anyone else? I'll file a bug against the ES spec if it's not just me :-)