SFML community forums

Help => General => Topic started by: Chunker120 on May 27, 2013, 01:22:31 pm

Title: Code is structured to use a global sf::RenderWindow, how can I fix this?
Post by: Chunker120 on May 27, 2013, 01:22:31 pm
I am making a game, and I noticed that it has some weird issues. For example, when I switch to the game window I can't switch to another window, almost as if it's stuck (The game is running smooth though). And sometimes, when using ALT+TAB to switch betwen windows, the game crashes and says abort() was called.

In another linux thread I heard that using a global sf::RenderWindow is very bad, and I wanted to fix it however I have been using this as a design choice for a while. Here's how my code is currently structured:

I declare a render window in main.cpp and wherever I need it I just call extern MyWindow and use the render window rather than using it as a function argument, mostly because it looks cleaner.

Is there a simpler way to fix this flaw? Is it the real cause of my problem?
Title: Re: Code is structured to use a global sf::RenderWindow, how can I fix this?
Post by: Lethn on May 27, 2013, 01:26:03 pm
I'm a windows user and still learning so I couldn't say for sure what your problem is, but have you tried using an OpenGL window instead to see if that changes anything? If it doesn't, it might be something to do with the way your code is put together and that would need someone more experienced to have a look.

I have noticed in general games just don't like alt-tabbing a lot, especially if they're in fullscreen, that's why developers often offer up windowed modes.
Title: Re: Code is structured to use a global sf::RenderWindow, how can I fix this?
Post by: Chunker120 on May 27, 2013, 01:30:17 pm
I'm a windows user and still learning so I couldn't say for sure what your problem is, but have you tried using an OpenGL window instead to see if that changes anything? If it doesn't, it might be something to do with the way your code is put together and that would need someone more experienced to have a look.

I have noticed in general games just don't like alt-tabbing a lot, especially if they're in fullscreen, that's why developers often offer up windowed modes.

I really have no knowledge in OpenGL. if I did have any openGL knowledge I probably wouldn't be using SFML, which makes everything much simpler for me. :P

The code structure is pretty good, but it's this window problem that's causing me problems.
Title: Re: Code is structured to use a global sf::RenderWindow, how can I fix this?
Post by: Nexus on May 27, 2013, 01:31:11 pm
Yes, global variables are really error-prone (initialization and destruction order, multithreading, no access control, lots of dependencies). Even more sf::RenderWindow, never make it global.

I declare a render window in main.cpp and wherever I need it I just call extern MyWindow and use the render window rather than using it as a function argument, mostly because it looks cleaner.
That's not cleaner, actually it's the opposite. You should really not use global variables.

I don't actually see the problem with parameters: It's not that you have to pass the window everywhere -- just where you need it. If you end up passing it everywhere, that's a good hint to reflect about your design, since only a few parts actually need the window. Drawable entities do not need to know it -- it is enough if the class that draws them has knowledge of the window.

This topic has been discussed many times, you find more information if you search the forum.
Title: Re: Code is structured to use a global sf::RenderWindow, how can I fix this?
Post by: MorleyDev on May 27, 2013, 04:34:46 pm
It may require a lot of re-factoring, but it strikes me as the best solution to have a renderer that knows how to draw the world, and not a world that knows how to draw itself. Or to be more specific, you shouldn't *need* to be sharing sf::RenderWindow around like crazy.

I'm of the opinion entities in the world shouldn't know how to draw themselves, it's not a responsibility they should have. This way the renderer can encapsulate the SFML graphical knowledge, such as RenderWindow, inside itself and not need to share such knowledge with the rest of the system.