SFML: Different drawing order when rendering multiple widow,

[tnutty]

This is a C++/SFML/opengl application.

Ok here is the draw function for a grid like box.

Code: [Select]


//draws a simple grid

void draw(sf::RenderWindow& canvas)const{
            for(int i = 0; i < HEIGHT; ++i){
                for(int j = 0; j < WIDTH; ++j){
                    if(m_list[i][j].piece.get() != NULL){     //[1]
                        m_list[i][j].piece->draw(canvas);  
                    }
                    canvas.Draw(m_list[i][j].sprite);  //[2]
                }
            }
            canvas.Draw( m_background ); //[3]
        }


Here is an example of the rendered image https://imgur.com/7AzVN

Assume [1] is always false for now. Now from the picture you see that [3] gets drawn first then [2] gets drawn. Thats fine and dandy, although I think that's somewhat backwards.  Now in the same application, when event X happens, I created another window, which uses the above
code. And I would figure, it would render the same image as shown previously, when correct settings are placed. But actually, what I am seeing is that, in the new window( which is setActive now) it actually draws [2] first then [3]. And hence [2] gets covered by [3], since [3] covers a greater area than [2]. Why the difference? This is basically the second window creation code :

Code: [Select]



PromotionPiecePicker::PromotionPiecePicker(const sf::RenderWindow& window): mainWindow(window){
        m_window.Create(sf::VideoMode(400,400,32), "Promition Picker");
        m_window.Clear(sf::Color::White);
        m_grid.setBackgoundColor(sf::Color::White);
        m_grid.setCellColor(sf::Color::Red);
        m_window.SetFramerateLimit(60);
    }

    detail::IChessPieceEnums::PieceType PromotionPiecePicker::getUserPick()
    {
        m_window.SetActive();

        detail::IChessPieceEnums::PieceType pieceType;

        while(m_window.IsOpened())
        {
            sf::Event event;
            //handle event
            while(m_window.GetEvent(event))
            {
                // Close window : exit
                if (event.Type == sf::Event::Closed){
                    m_window.Close();
                }

                // Escape key : exit
                if ((event.Type == sf::Event::KeyPressed) && (event.Key.Code == sf::Key::Escape)){
                    m_window.Close();
                }
                /* handle event */
                if(m_window.GetInput().IsMouseButtonDown(sf::Mouse::Left)){
                    m_window.Close();
                    cout << "in event\n";
                }
            }
            glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

            _displaySelections();

            m_window.Display();
        }

        //make main window active again
        mainWindow.SetActive();

        return pieceType;
    }
    void PromotionPiecePicker::_displaySelections(){
        m_grid.draw(m_window);
    }


Any advice guys?  You can actually see the whole code here in github.  The above code is from PromotionPiecePicker.cpp class.

https://github.com/d...aster/ChessGame

[Mario]

You always have to draw vom back to front, but also don't mix in OpenGL calls (unless you tell SFML you're do so by saving/restoring the state).

Instead of "glClear()" use "RenderWindow::Clear()". Didn't try the code, so there might be more issues.

[tnutty]

You always have to draw vom back to front, but also don't mix in OpenGL calls (unless you tell SFML you're do so by saving/restoring the state).

Instead of "glClear()" use "RenderWindow::Clear()". Didn't try the code, so there might be more issues.

Yea I tried that first but there was a problem. The problem was that, RenderWindow::Clear() would clear the screen and keep it that way. Meaning, it would clear the screen with white background and not show any graphics. Any idea on why?

[tnutty]

Hey Mario, looks like your tip led me to correct my problem. I was indeed mixing opengl calls and sfml without saving context and that was causing a problem with the rendering; it made every render scheme backwards. So I thank you. Problem solved. All I did was remove some of the opengl calls I was using.