The list of common mistakes is very long, and hard to read. The entries should be split into categories, perhaps also into different pages. I'm not sure how to categorize them, else I wound have done it.
I'm not sure who wrote the line above. Please type a tilde 4 times to sign. Now about the Paletted textures section. I have noticed someone has edited to add the following "But there are still a lot of video cards around that don't support shaders, so you'll have to implement it using GL_EXT_paletted_texture as well.". There is an assumption being made that if a hardware doesn't support shaders, that it supports GL_EXT_paletted_texture. Furthermore, that section was added by me since I noticed that a few users were getting surprised that that extension was dropped. We don't need to tell the programmer there are a lot of hardware out there that supports GL_EXT_paletted_texture. That's ridiculous. For that reason, I'm pulling that text out. V-man 12:59, 3 July 2011 (PDT)
It was me who posted the fist line, I thought the timestamps were added automatically back then. --Zyx 2000 14:06, 4 July 2011 (PDT)
I have moved some sections related to deprecated features to a separate article. I still believe this article is too long, and I might split it up more in the future. --Zyx 2000 14:05, 9 July 2011 (PDT)
"On which platforms is GL_BGRA preferred? Making a list would be too long but one example is Microsoft Windows."
Does such a list exist somewhere? I am currently developing an OpenGL-based library for which I cannot require 4.3, and would rather avoid possibly missing extensions to use ARB_internalformat_query2. --WilliamKappler (talk) 13:24, 8 February 2016 (EST)
Texture C++ class example code
Regarding the newly added sample code for a C++ texture class, I would like to propose the following changes: First, zero-initialize the internal handle, like "GLuint obj_ = 0;". Second, add a default constructor, like "MyTexture() = default;". These changes should hopefully prevent some bugs with uninitialized data, and also save users of this code the trouble of properly defining the default constructor. Nguillemot (talk) 23:32, 21 October 2017 (UTC)
- Adding a default constructor is not necessary. If the user does not heed the "Other constructors as normal" comment, they will find that they cannot construct the type at all. By the rules of C++, default constructors are disabled if the class has a user-provided constructor. This includes the move constructor. Adding a default member initializer however is reasonable. Alfonse (talk) 04:12, 22 October 2017 (UTC)