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

Author Topic: Global vars  (Read 3366 times)

0 Members and 1 Guest are viewing this topic.

cdesseno

  • Newbie
  • *
  • Posts: 4
    • View Profile
Global vars
« on: March 07, 2010, 09:12:21 pm »
This question is more a general question than a SFML one. How I may declare the "sf::RenderWindow App" so I can use it in every class? Or is better passing it by a parameter?

Thanks.

RetroX

  • Newbie
  • *
  • Posts: 13
    • View Profile
Global vars
« Reply #1 on: March 07, 2010, 10:10:30 pm »
It's perfectly fine to define a RenderWindow outside of the main() function.  You just can't actually do anything with it until it's within the functions.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Global vars
« Reply #2 on: March 08, 2010, 12:19:53 am »
It's always better to encapsulate the render window. Normally only some classes of your application need it. In those cases it's better to give a reference to it. For example, you may use methods like:

Code: [Select]
void Render( sf::RenderTarget& target );

Walker

  • Full Member
  • ***
  • Posts: 181
    • View Profile
Global vars
« Reply #3 on: March 08, 2010, 03:59:33 am »
I'm not sure if I'm doing it "correctly", but I usually try not to need to do this.

I try to make my classes (except for window/drawing classes) never have to access the window themselves.

For example, if you have a class that has a sprite you need to draw, you can write a getSprite() function, that returns the sprite. Then do

Code: [Select]
RenderWindow.Draw (object.getSprite());

Someone else can hopefully explain whether or not this is a good idea...  :lol:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Global vars
« Reply #4 on: March 08, 2010, 08:28:07 am »
Quote
Someone else can hopefully explain whether or not this is a good idea...

A class should offer services, not data. So actually, this would be a better idea:
Code: [Select]
object.Draw(RenderWindow);
This way nobody has to know that object is drawn with a sprite, all we know about this object is that it is able to draw itself into a render target.

A class that provides services and hides its internal data is generally more flexible and maintainable.
Laurent Gomila - SFML developer

Walker

  • Full Member
  • ***
  • Posts: 181
    • View Profile
Global vars
« Reply #5 on: March 08, 2010, 08:37:45 am »
Yes, that makes much more sense.

Quote
A class should offer services, not data.

I probably would have told someone that even though I'm not really doing it myself, lol.

Thanks for the tips