[solved] Error 1282 when glBindVertexArray

[Keeeo]

Hello, what is RenderWindow::display() doing to my VAO?

glBindVertexArray(vao);
glGetError(); // OK

glDrawArrays(GL_TRIANGLES, 0, ms->g_vertex_buffer_data.size() / 3);
glBindVertexArray(0);
glGetError(); // OK

window.display(); // WITHOUT THIS CALL, IT'LL BE OK
glGetError(); // OK

// NEXT LOOP

glBindVertexArray(vao);
glGetError(); // ERROR 1282
 

(here is exactly same problem, http://www.gamedev.net/topic/645689-invalid-operation-error-on-glbindvertexarray/)

[binary1248]

Make sure to call window.setActive() before creating your VAO or doing any other OpenGL stuff for that matter. SFML likes to juggle contexts every now and then (including when calling window.display()), and VAOs are not shareable resources, so you have to make sure they are created in the same context as the one you use them in.

[Keeeo]

Great call, it became inactive after loadFromImage call. I have class that handles shader, which is called after creating window. LoadFromImage makes window inactive and forcing it active after loading image seems like bad idea. It was deactivated surely for some reason. Can i actually use sf::Shader and handle OpenGL calls myself?

(click to show/hide)

namespace view
{
   WorldShader::WorldShader()
   {
   }

   WorldShader::WorldShader(view::Window* window)
   {
      bool ret = shader_.loadFromFile("./shaders/world.vert", "./shaders/world.frag");
      assert(ret);

      sf::Shader::bind(&shader_);
      glGetIntegerv(GL_CURRENT_PROGRAM, &shaderId_);
      assert(shaderId_ != -1);
      sf::Shader::bind(NULL);

      modelLoc_ = glGetUniformLocation(shaderId_, "model");
      viewLoc_ = glGetUniformLocation(shaderId_, "view");
      projectionLoc_ = glGetUniformLocation(shaderId_, "projection");

      assert(modelLoc_ != -1);
      assert(viewLoc_ != -1);
      assert(projectionLoc_ != -1);

      img_.loadFromFile("./textures/cubes.png");
      tex_.loadFromImage(img_); // THIS CALLS MAKES WINDOW INACTIVE
      window->setActive();
      shader_.setParameter("sampler", tex_);
   }

   void WorldShader::loadModelMatrix(glm::mat4* model)
   {
      glUniformMatrix4fv(modelLoc_, 1, GL_FALSE, glm::value_ptr(*model));
   }

   void WorldShader::bind()
   {
      sf::Shader::bind(&shader_);

      CameraData cd;
      Post(EEvent::FetchCameraData, &cd, 0);
      assert(cd.position != NULL);
      assert(cd.projection != NULL);
      assert(cd.view != NULL);

      glUniformMatrix4fv(viewLoc_, 1, GL_FALSE, glm::value_ptr(*cd.view));
      glUniformMatrix4fv(projectionLoc_, 1, GL_FALSE, glm::value_ptr(*cd.projection));
   }

   void WorldShader::unbind()
   {
      sf::Shader::bind(NULL);
   }

   WorldShader::~WorldShader()
   {
   }

}
 

[binary1248]

Great call, it became inactive after loadFromImage call. LoadFromImage makes window inactive and forcing it active after loading image seems like bad idea. It was deactivated surely for some reason.

This is... let's say... a "defect" that we are aware of. It isn't a bug because this is intended behaviour, and was the only way to fix another real bug within sfml-graphics a while back. It sucks, but at least now you know .

The first calls (whether direct or indirect) to sf::Texture::getMaximumSize() and sf::Shader::isAvailable() have to create a temporary context to make sure things work out if they are called before a window is created. This leads to the deactivating you are experiencing. If you call these 2 functions at the start of your application, any texture or shader calls after that shouldn't unexpectedly deactivate the context any longer.

This is also documented here and here. But yeah... I guess you couldn't have known about this.

Can i actually use sf::Shader and handle OpenGL calls myself?

You can. Currently, sf::Shader is very... limited if you want to use it with other OpenGL code yourself. It was more designed to complement what sfml-graphics could already do. If the sf::Shader API can't do something that you need, currently you would have to resort to extracting the object name like you do in your code example. Soon (SFML 2.3) sf::Shader will allow you to retrieve its name directly through a method call as well.

[Keeeo]

Thanks very much for the explanation. Although i understand that this is documented and i should just rtfm, theres no way i would ever find it. I would never look into documentation for functions with names like this.

[binary1248]

I know... I also didn't expect you to find it since it was completely unrelated .