GLDELETERENDERBUFFER(3G)

🌸 NAME 🌸

okay so this is the GLDELETERENDERBUFFER page from manual section 3G β€” and yeah the header has a little [FIXME: manual] placeholder, we love a work in progress πŸ’… β€” and it's all about deleting renderbuffer objects. That's literally the whole vibe. ✨

✨ C SPECIFICATION ✨

The signature is exactly this, no cap:

void glDeleteRenderbuffers(GLsizei n, GLuint *renderbuffers);

πŸŽ€ PARAMETERS πŸŽ€

  • n β€” specifies the number of renderbuffer objects to be deleted. Like, how many are we deleting today, bestie?
  • renderbuffers β€” a pointer to an array containing n renderbuffer objects to be deleted. It's giving "here's the list, handle it". 🫢

πŸ’– DESCRIPTION πŸ’–

So glDeleteRenderbuffers deletes the n renderbuffer objects whose names are stored in the array addressed by renderbuffers. Basically: you bring the names, it brings the deletion.

The name zero is reserved by the GL and is silently ignored should it occur in renderbuffers β€” and same for other unused names. So don't stress about those, they're not gonna cause drama.

Once a renderbuffer object is deleted, its name is again unused and it has no contents. Empty. Void. Gone. Iconic.

If a renderbuffer that is currently bound to the target GL_RENDERBUFFER is deleted, it is as though glBindRenderbuffer() had been executed with a target of GL_RENDERBUFFER and a name of zero. So the binding gets reset to zero, lowkey tidy.

If a renderbuffer object is attached to one or more attachment points in the currently bound framebuffer, then it's as if glFramebufferRenderbuffer() had been called, with a renderbuffer of zero for each attachment point to which this image was attached in the currently bound framebuffer. In other words, this renderbuffer object is first detached from all attachment points in the currently bound framebuffer. The way it just detaches itself from the bound framebuffer? Obsessed.

⚠️ Important caveat, bestie: the renderbuffer image is specifically not detached from any non-bound framebuffers. So it only detaches from the currently bound framebuffer. Don't get it twisted. πŸ™ˆ

πŸ’€ ERRORS πŸ’€

  • GL_INVALID_VALUE is generated if n is negative. So yeah, negative n is a no-no and the GL will literally let you know.

🌈 VERSION SUPPORT 🌈

The feature name here is glDeleteRenderbuffers, and here's the OpenGL version tea β˜• β€” every mark is exactly what the original table says, just in list form because tables aren't the move here:

  • 2.0 β€” -
  • 2.1 β€” -
  • 3.0 β€” βœ”
  • 3.1 β€” βœ”
  • 3.2 β€” βœ”
  • 3.3 β€” βœ”
  • 4.0 β€” βœ”
  • 4.1 β€” βœ”
  • 4.2 β€” βœ”
  • 4.3 β€” βœ”
  • 4.4 β€” βœ”
  • 4.5 β€” βœ”

So: 2.0 and 2.1 get a -, and 3.0 through 4.5 get a βœ”. Periodt. πŸ’…

πŸ¦‹ SEE ALSO πŸ¦‹

Go give these a read too, bestie:

  • glGenRenderbuffers()
  • glFramebufferRenderbuffer()
  • glRenderbufferStorage()
  • glRenderbufferStorageMultisample()

Copyright Β© 2010-2014 Khronos Group. This material may be distributed subject to the terms and conditions set forth in the Open Publication License, v 1.0, 8 June 1999. http://opencontent.org/openpub/.

Copyright Β© 2010-2014 Khronos Group


okay bestie, that's the whole page! The footer vibe is: source/version [FIXME: source], dated 08/09/2021, and the page title is GLDELETERENDERBUFFER(3G). Mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from