Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Problem with sf::Shader after updating  (Read 5154 times)

0 Members and 1 Guest are viewing this topic.

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Problem with sf::Shader after updating
« on: July 17, 2014, 11:15:19 pm »
Hi there!
I updated my SFML repo to the current master recently and now using sf::Shader seems to be broken...
Whenever setParameter() or bind() or the destructor is called I get a: "An internal OpenGL call failed in Shader.cpp (421) : GL_INVALID_VALUE, a numeric argument is out of range" error in the console. (line number changes respectivly to the calling method of course)

I investigated a little bit and it seems that m_ShaderProgram is invalid. When I step through the compile() method with the debugger it stops in line 490 where m_ShaderProgram is created. The method return on this line (eventough there is no return?!) and m_ShaderProgram stays at 0.
Through checking out different git commits if found that 1fe22e2 seems to be the breaking commit. Before that everything works fine.
I don't quiet understand why. But can somebody explain to me whats going on? Or has anybody experienced similar problems?

Thanks a lot, Foaly
« Last Edit: July 17, 2014, 11:27:23 pm by Laurent »

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Problem with sf::Shader after updating
« Reply #1 on: July 17, 2014, 11:37:29 pm »
Operating system? Compiler? Driver version? Does the Shader example run properly? Minimal code?

The primary reason for such weird "return where there is no return" is often some form of optimization still being enabled. With GCC, you should check if -O0 is present or if there is another optimize option already enabled. In some configurations, you can tell it to compile with debugging symbols and optimizations enabled, which makes little sense if you intend to debug line by line.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Problem with sf::Shader after updating
« Reply #2 on: July 17, 2014, 11:48:11 pm »
Oh i forgot to include that.
I am running a windows 8 machine with MinGW gcc version 4.8.1 and a NVIDIA card with latest drivers (337.88).
I compiled the shader example in debug and release mode and it seems to work properly.
I checked the compile setting and in debug mode there is no optimization enabled. The compile command is:
mingw32-g++.exe -std=c++11 -Wall  -pg -g -DDEBUG    -I"F:\Librarys\official SFML\install\include"  -c "F:\Eigene Programme\Crazy Painter\main.cpp" -o obj\Debug\main.o
I will try to put a minimal example together tomorrow.
« Last Edit: July 17, 2014, 11:51:57 pm by Foaly »

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Problem with sf::Shader after updating
« Reply #3 on: July 18, 2014, 05:18:50 pm »
ok i wrote a minimal example and... it compiles just fine.
So something else must be wrong. There is also two render textures involved, so I though it might be related to the context management. (because in the commit a dummy context is created)

And indead, when I move my Shader loading code before my rendertexture creation code I get the following error:
An internal OpenGL call failed in RenderTextureImplFBO.cpp (117) : GL_INVALID_OP
ERATION, the specified operation is not allowed in the current state
Impossible to create render texture (failed to link the target texture to the fr
ame buffer)
An internal OpenGL call failed in Shader.cpp (115) : GL_INVALID_VALUE, a numeric
 argument is out of range


I tryed to replicate the error with two renderTextures in a minimal example, but I couldn't. I don't really know how to debug the context code (which one is active etc.). So where do I go from here?

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Problem with sf::Shader after updating
« Reply #4 on: July 18, 2014, 05:32:31 pm »
So... is there no way to make a minimal example out of this information? From what you have reported, it seems rather simple...
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Problem with sf::Shader after updating
« Reply #5 on: July 18, 2014, 07:37:49 pm »
Ok so I noticed that the program compiles fine in release mode, so I looked at what is done different in debug and release builds. In debug mode I log some information about the host system. The method sf::Texture::getMaximumSize() seems to break the Shader code.
The following code does not work for me (ie. the Shader is not created, and there is OpenGL errors):
#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

// Shader Bug Test
int main()
{
    // comment the following line and everything works as expected
    std::cout << "Maximale Texturgröße: " << sf::Texture::getMaximumSize() << std::endl;

     // create the window
    sf::RenderWindow window(sf::VideoMode(800, 600), "My window");
    window.setFramerateLimit(60);

    if(!sf::Shader::isAvailable()) {
        std::cout << "Shader not available!" << std::endl;
    }

    sf::Shader m_FadeShader;
    m_FadeShader.loadFromFile("FadeShader.frag", sf::Shader::Fragment);
    m_FadeShader.setParameter("fRate", 0.5f);

    sf::RectangleShape rect(sf::Vector2f(200, 200));
    rect.setPosition(300, 200);

    // run the program as long as the window is open
    while (window.isOpen())
    {
        // check all the window's events that were triggered since the last iteration of the loop
        sf::Event event;
        while (window.pollEvent(event))
        {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)
                window.close();


            // Escape key pressed, close window
            if(event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
                window.close();
        }
        // clear the window with black color
        window.clear(sf::Color::Black);

        // draw everything here...
        window.draw(rect, &m_FadeShader);

        // end the current frame
        window.display();
    }

    return 0;
}
 
Shader code:
uniform float fRate;

void main()
{
    vec4 color = vec4(1.0, 1.0, 1.0, 1.0);
    color.a -= fRate;
    gl_FragColor = color;
}

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Problem with sf::Shader after updating
« Reply #6 on: July 18, 2014, 08:21:03 pm »
Man... this is exactly the same issue as #211. I guess sf::Shader::isAvailable() wasn't the only thing that needed fixing... ::)

If you feel like it, you can try applying the same code changes as this commit to sf::Texture::getMaximumSize() as well and see if it fixes the issue.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Problem with sf::Shader after updating
« Reply #7 on: July 18, 2014, 08:46:30 pm »
Awesome thanks! I have to go now, but I will try to write a fix later.

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Problem with sf::Shader after updating
« Reply #8 on: July 19, 2014, 12:51:09 am »
I fixed it! It's in a branch in my repo. In this commit.
Unfortunatelly I messed something up when I pulled from orgin or upstream to my repo. Because when I try to send a pull request now, I have about 150 old SFML commit together with my commit... So is there any other way you can integrate this? Or tell me how to fix it. That would be awesome!

I have one question to why it was broken before. Isn't ensureGlContext() supposed to do exactly what is done now manually? Create a dummy context.

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Problem with sf::Shader after updating
« Reply #9 on: July 19, 2014, 01:15:43 am »
It creates a thread local context too early, before the shared context exist. Because of that, once the shared context actually does exist and the contexts start sharing objects with each other, the one created locally in the current thread will be isolated from the others because it didn't have the shared context to share with.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: Problem with sf::Shader after updating
« Reply #10 on: July 19, 2014, 01:16:14 am »
Ok nevermind. After some trying I was able to make a clean pull request. It can be found here.

edit: haha I did not understand that! sounds complicated. well I am glad this fixes it :D
« Last Edit: July 19, 2014, 01:17:45 am by Foaly »

 

anything