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

Author Topic: Code is structured to use a global sf::RenderWindow, how can I fix this?  (Read 4128 times)

0 Members and 1 Guest are viewing this topic.

Chunker120

  • Newbie
  • *
  • Posts: 31
    • View Profile
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?

Lethn

  • Full Member
  • ***
  • Posts: 133
    • View Profile
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.
« Last Edit: May 27, 2013, 01:28:27 pm by Lethn »

Chunker120

  • Newbie
  • *
  • Posts: 31
    • View Profile
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.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

MorleyDev

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
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.
« Last Edit: May 27, 2013, 04:36:55 pm by MorleyDev »
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.