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

Author Topic: Second RenderWindow going nuts (OpenGL related)  (Read 1780 times)

0 Members and 1 Guest are viewing this topic.

gws923

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Second RenderWindow going nuts (OpenGL related)
« on: December 11, 2013, 05:44:21 pm »
Hello, everyone.  Let me preface this by saying I know pretty much zilch about OpenGL.  I shall also say that none of these problems occurred when I compiled with g++ on Windows 7.  These problems are all occurring now that I am trying to run my program on OSX 10.8.5.

The program I am building is a level editor for a game I am making.  In the editor, you can save and test the level you are working on.  In Windows, you press a hotkey and a new RenderWindow appears, loading the level you just created and you can play it and everything is peaches and magic.

When I began trying to build this thing on OSX, I ran into the following problem:

When my second window opens, it looks like someone threw up on the screen.  I can't describe what comes up other than graphics card chaos.  Or, every once in a while, it just comes up black.  The sounds that should play do, and nothing crashes, so it really does appear just to be a problem with graphics.

If, I switch focus to another window, and then switch focus BACK to the test game window, it begins drawing normally.  Which is nice, but it would sure be swell if it worked the first time.

Additional details:
1.) In Windows, I can close the test game window and test again just fine as many times as I like. In OSX, when I test a second time, the screen displays without the throwup on it, but it doesn't update.
2.) My project is giving me linker errors to OpenGL when I try to use any OpenGL methods, which I could fix but I'd rather not have another library dependency if I don't have to.

Related code:
This comes from my Editor.cpp, which basically runs the level editor:
void Editor::loop()
{
    while (true)
    {
        if(_running) // Editor is on
        {
            // Process input for the editor.
            processInput();
           
            // Prepare for drawing.
            _rw->setActive(true);         // _rw is my render window.
            _rw->pushGLStates();        // no idea if this is helping
            _rw->clear();

            // Update all objects.
            _objectMan->update();
           
            // Draw all objects.
            _rw->setView(_contentView);
            _objectMan->draw();

            // Call display on the render window.
            _rw->popGLStates();      // again, no idea if this is doing anything.
            _rw->display();

        }
        else if(_testGame)  // An instance of TestGame class is running.
        {
            _rw->pushGLStates();
            _testGame->run();
           
            // When finished
            _testGame = NULL;
            _rw->popGLStates();
            _running = true;
        }
    }
}
 

I won't bother posting the code, but I will mention that in Editor::ProcessInput(), pressing ctrl + t sets _testGame to a new TestGame() and sets Editor::_running to false.

Here's the code in TestGame::gameLoop():  (Actually is Game::gameLoop() which is TestGame's superclass.)
void TestGame::gameLoop()
{
    while (_running)
    {
        // Get the active state from the StateManager.
        State::Ptr activeState = _stateMan->activeState();

        // If activeState is null, then we're done with the game.
        if (!activeState) break;

        // Process input for the game and for the active state.
        processInput(activeState);

        // Update the state.
        activeState->update();

        // Prepare for drawing.
        _rw->setActive(true);     // Seems like it should be here but I really don't even know.
        _rw->clear();

        // Draw the state.
        _rw->pushGLStates();     // Do I need this?
        activeState->draw();
        _rw->popGLStates();      // Who knows?

        // Call display on the render window.
        _rw->display();
    }

}

Thanks, as always, for your help.  I'm hoping that this problem is all created by me being a dummy rather than a super complicated OpenGL mess that is going to mean learning OpenGL backward and forward.  But if that's what I must do then I suppose I will do it!

gws923

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Re: Second RenderWindow going nuts (OpenGL related)
« Reply #1 on: December 12, 2013, 03:49:18 pm »
Ok, so after checking out some issues on the SFML repository on github, it seems like this may be a problem of OpenGL 3.2 still not being supported for OSX.  I also see that in the window tutorial, OSX can only support render windows and event handling in the main thread, which might be my problem.  I suppose I can work around this by rewriting my game class.  If I have any success I will update, even though it doesn't seem there's much interest.

Really the only reason I wanted this to work on OSX was so that the artist who's working on this project with me could use the level editor (he has a mac), but I suppose it's not essential.

Still, I'd love to know if anyone had any updates on OpenGL 3.2 support for OSX.  It looks like it's currently scheduled for 2.x...

gws923

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Re: Second RenderWindow going nuts (OpenGL related)
« Reply #2 on: December 18, 2013, 02:51:29 pm »
Just thought I'd follow up on this because I just resolved the issue.  In case anyone ever has a similar problem.

The issue was, indeed, created by the sort of wonky support for OpenGL on OSX.  I had been creating my second RenderWindow in my TestGame class, in other words, not in the same thread as my first RenderWindow, which for OSX is apparently a no-no.

All I had to do was create and initialize the RenderWindow in my Editor class implementation (where the first one was created too) and then pass it as an argument to TestGame and have TestGame run it.  It worked with no fuss.

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Back to C++ gamedev with SFML in May 2023