Question

i have been trying to add support for GL_RGB_422_APPLE.

internalFormat = GL_RGB;

pixelFormat = GL_RGB_422_APPLE;

PixelType = GL_UNSIGNED_SHORT_8_8_APPLE;

glTexImage2D(GL_TEXTURE_2D, 0, InternalFormat, 2048, 2048, 0, PixelFormat, PixelType, 0);

But `glCheckFramebufferStatus` is returning GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT error.

it is working well for following formats : internalFormat = GL_RGB;

pixelFormat = GL_RGB;

PixelType = GL_UNSIGNED_BYTE;

is there any other steps to do to support GL_RGB_422_APPLE ?

In our project we are using a texture that just stores bool values(0/1) for every pixel. For storing a bool values 16bits/pixel is so costlier.that is why i'm looking for above implementation.

Was it helpful?

Solution

You, as a mere OpenGL developer, cannot "add support" for anything. That's the job of an implementor. With OpenGL ES (GLES) 2.0, unless supported by an extension, you simply cannot use RGB_422_APPLE for framebuffer attachments. Actually, the GLES 2.0 spec doesn't even mention any sized internal formats. Oddly enough, they do use sized internal formats for the description of when framebuffer attachments are legal and don't compromise framebuffer completeness.

Anyway, even if you did have support for regular textures and RGBA_422_APPLE via the appropriate extension, that doesn't say anything about if and how the [sized internal] format is legal for use as a framebuffer attachment and from skimming the extension spec of said format, there is no indication that it is legal.

I guess you're out of luck in this particular case.

EDIT: To clarify, to be able to use a non-depth/non-stencil texture as a framebuffer attachment, it must be color-renderable. The above mentioned spec doesn't mention anything on that matter and the implementation you're using seems to think so as well.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top