example texture.scm not working

[Negdayen]

It just pops blank, black window for me and writes out GL error: invalid enum

Compiler warning:

texture.c: In function ‘fastRenderSpriteShader’:                                                                                                                                                                                             
texture.c:89:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]                                                                                                                                             
     glBindTexture(3553, (unsigned int)(data->uniformValues)[1]);                                                                                                                                                                            
                         ^                                                                                                                                                                                                                   
texture.c: In function ‘fastRenderArraysSpriteShader’:                                                                                                                                                                                       
texture.c:107:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]                                                                                                                                            
     glDrawArrays((data->mode), (GLint)(data->offset), (data->nElements));  

Sorry if not relevant, I'm still a C novice.

[AlexCharlton]

Hi @Negdayen, I'll answer here, but this applies to all the issues you opened.

Do any of the examples work for you or only the ones you opened issues for?

Chances are decent your window is not being properly initialized for your version of OpenGL. These tests don't try to do the work across all platforms, because doing so is kind of hard. Hypergiant tries to overcome this, but I see you saw limited success with it as well. Let me know what platform and OpenGL version you're using and we can try to figure out what's going on.

[Negdayen]

basic.scm and interactive.scm did work, also particles.scm in hypergiant worked--but not the particles.scm here.

Ubuntu 14.04 x86_64 OpenGL version string: 4.5.13399 Compatibility Profile Context 15.20.1013

[AlexCharlton]

Wow, so simple doesn't work, but interactive does. Those two files have the same OpenGL code! That's really tough to understand. Both of them were run with csi? What about compiling?

[Negdayen]

Yes they all exhibited the same behavior with csc and csi.

jacob@jxps:~/glls/examples$ csc -lGL basic.scm                                                                                                                                                                                               
jacob@jxps:~/glls/examples$ ./basic                                                                                                                                                                                                          
#(pipeline 5 shaders:(vertex: fragment:) attributes:((vertex 1 vec2:) (color 0 vec3:)) uniforms:((mvp 0 mat4:)))                                                                                                                             
#(pipeline 3 shaders:(vertex: fragment:) attributes:((vertex 1 vec2:) (color 0 vec3:)) uniforms:((mvp 0 mat4:)))      

Compiling interactive.scm works as well with the caveat it exits it immediately due to the main thread terminating I believe. I can see the graphic though with an added infinite loop to keep the window open :)

Yeah, simple.scm is just a black window plus a ton of GL error: out of memory messages when compiling and when interpreting.

[AlexCharlton]

So if you take interactive.scm, remove the thread-start!, the lambda around that main statement, and the thread-yield!, then it does it not work? Or is it something else I'm missing?

[Negdayen]

It's something else, works just fine with the threading removed.

[Negdayen]

changing (mesh-make-vao! rect (pipeline-mesh-attributes simple-shader)) to (mesh-make-vao! rect (pipeline-mesh-attributes simple-shader) #:dynamic) made simple.scm work. the out of memory messages are gone as well.

making the same change to texture.scm seems to have corrected the problem as well, although a GL error: invalid enum is still reported.

[AlexCharlton]

Wow, that's crazy! The difference between those should be immaterial, so the fact that it's not working either speaks to something wrong with your OpenGL implementation or (and this is altogether possible) I am not seeing something elsewhere.

If this is the case, then the basic.scm example from gl-utils should not work, while the other three examples will. This also means that, as far as I can see, the error is coming from one of two places: 1) The usage itself is triggering some failure -- this should never be the case, since the usage is just a hint to OpenGL: it should only optimize, not change results. 2) When the usage is static (the default), I take the liberty of deleting the vertex and index buffers belonging to the mesh after the VAO is created. This should also not make a difference, as an OpenGL implementation should keep those buffers in memory as long as something (in this case the VAO) has a reference to them.

Do you mind trying the examples from gl-utils (basic, and one other one), then deleting the whole when clause at the end of mesh-make-vao! in gl-utils-mesh.scm (line 405) and trying the examples again?

[Negdayen]

After applying the following comments, gl-utils's basic.scm successfully ran with both csc and csi. All other issues I recently opened up were also remedied by commenting these two expressions.

(when (member usage '(static: static-read: static-copy:))                                                                                                                                                                                
      (mesh-index-buffer-set! mesh #f)                                                                                                                                                                                                       
      (mesh-vertex-buffer-set! mesh #f)                                                                                                                                                                                                      
      (mesh-index-data-set! mesh #f)                                                                                                                                                                                                         
      (mesh-vertex-data-set! mesh #f)                                                                                                                                                                                                        
      #;(gl:delete-buffer vertex-buffer)                                                                                                                                                                                                     
      #;(when index-data (gl:delete-buffer index-buffer)))

[AlexCharlton]

That's really good news!

My reading of the OpenGL spec would seem to indicate that it should be permissible to delete VBOs after binding them to a VAO. From section 5.1.2:

Attachments to unbound container objects, such as deletion of a buffer attached to a vertex array object which is not bound to the context, are not affected and continue to act as references on the deleted object, as described in the following section.

And 5.1.3::

When a buffer, texture, sampler, renderbuffer, query, or sync object is deleted, its name immediately becomes invalid (e.g. is marked unused), but the underlying object will not be deleted until it is no longer in use. A buffer, texture, sampler, or renderbuffer object is in use if any of the following conditions are satisfied: • the object is attached to any container object • the object is bound to a context bind point in any context • any other object contains a view of the data store of the object.

So I'd be interested in knowing what hardware/drivers you're using that have this issue. However, since my goal is not to enforce correct OpenGL behaviour, but rather to make something that works, I'll remove the offending code. The benefits it offered were pretty minuscule, anyway.

Thanks so much, @Negdayen for getting to the bottom of this!

[AlexCharlton]

Fixed by https://github.com/AlexCharlton/gl-utils/issues/4

[Negdayen]

I'm using a Radeon HD 5770 with fglrx-updates. Thanks for the help.