Talk:OpenGL Programming/Modern OpenGL Tutorial 06

Why not develop these examples for egl/gles rather than glew, glut and so on? There are more developers targeting phones and tablets than PCs these days. The example can end up simpler too (fewer headers to include and fewer libraries to link against). On my netbook with Intel graphics I can't even run this example, but OpenGL ES 2.0 is supported.
 * I'm delighted that these pages suit my tastes, namely the desktop PC and (nearly) plain C. 81.131.15.234 (discuss) 23:30, 29 May 2013 (UTC)
 * Setting up an EGL requires some boilerplate and doesn't work an old desktops. Since then, FreeGLUT was ported to Android (by me ;)), and also I just switched to SDL2 for the samples, so that'll work on mobile targets too :) Beuc (discuss • contribs) 20:02, 18 August 2015 (UTC)

The "mytexture" uniform
In the source code for this tutorial, the uniform "mytexture" is "bound":

uniform_name = "mytexture"; uniform_mytexture = glGetUniformLocation(program, uniform_name);

This isn't mentioned on the page. Consequently I wrote my code without that call. It shouldn't have worked, but it did. So then I commented out "glUniform1i(uniform_mytexture, 0);" from the render stage, and it still worked. I even changed the name of the uniform in the fragment shader, so that it definitely referred to nothing outside of the shader, and the texture still appeared. What's going on there?

Replacing it with a zero (gl_FragColor = texture2D(0, f_texcoord);) stopped the texture showing up, so that call is doing something. 81.131.15.234 (discuss) 23:37, 29 May 2013 (UTC)


 * Oh, OK, I get it now. All "binding" does is make it possible to set the value of the uniform (from my C code). When left unbound, it has a default value of zero (or an undefined value which happened to be zero). The purpose of that uniform was only to convey the number of the slot that the texture is held in, which is slot 0. So all I wanted to do was send a zero to the shader. My failure to properly carry out all the steps needed to do that didn't matter, because the zero was there anyway by default, and that's how the texture showed up. TL;DR: maybe somebody should edit the page to add a part about binding the uniform. 81.131.38.152 (discuss) 01:00, 30 May 2013 (UTC)


 * I'm making a pass on the pages to upgrade to SDL2, I'll see what I can do :) Beuc (discuss • contribs) 20:02, 18 August 2015 (UTC)

Defining images in C code is not a memory issue
The page says "Note: Bundling images as C code is not super-memory-efficient, so don't generalize it. Technically: it's stored in the program BSS segment rather than in the heap, so it cannot be freed." Actually the data goes into the "text" segment with the code and any other const data. The OS can free the physical memory used to hold the image data since it can always be paged in from the file when its accessed.

I recommend just removing that Note.

Tommay (discuss • contribs) 05:59, 18 September 2013 (UTC)


 * Yeah actual memory usage can be obscure since the OS is doing so many things. I removed all the paragraph since I stopped trying to load the pixels in such as raw way ;) Beuc (discuss • contribs) 20:02, 18 August 2015 (UTC)

Remember texture_id is a GLOBAL variable when loading from SOIL
Somewhat of a daft mistake on my part but remember to use the global variable texture_id when loading an image from SOIL. I'd made a local variable within the init_resources function and spent the best part of an hour trying to work out why my cube was black. The local variable that pointed to the texture was destroyed when the init_resources function went out of scope, hence the black cube.