It takes a target parameter, but the only viable target is GL_RENDERBUFFER.
http://www.opengl.org/wiki/Renderbuffer_Object
https://www.khronos.org/opengles/sdk/docs/man/xhtml/glBindRenderbuffer.xml
http://www.opengl.org/wiki/GlRenderbufferStorage
(I'm just learning OpenGL, and already found these two today; maybe I can expect this seemingly-useless target parameter to be common in many functions?)
There is bit of the rationale behind the target parameter in the issue 30 of the original EXT_framebuffer_object extension specification. (I generally recommend people to read the relevant extensions specs even for features which have become core GL features, since those specs have often more details, and sometimes contain bits of reasoning of the ARB (or vendors) for doing things one way or the other, especially in the "issues" section.):
(30) Do the calls to deal with renderbuffers need a target parameter? It seems unlikely this will be used for anything.
RESOLUTION: resolved, yes
Whether we call it a "target" or not, there is some piece of state in the context to hold the current renderbuffer binding. This is required so that we can call routines like RenderbufferStorage and {Get}RenderbufferParameter() without passing in an object name. It is also possible we may decide to use the renderbuffer target parameter to distinguish between multisample and non multisample buffers. Given those reasons, the precedent of texture objects, and the possibility we may come up with some other renderbuffer target types in the future, it seems prudent and not all that costly to just include the target type now.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With