Accessing RenderWindows

[malachipclover]

I need some help with a good way to access my RenderWindow.  I would rather not put all my rendering code in main.cpp where it is declared, but I'm not seeing a way to access the window from anywhere else.  If I declare it in a header file, I get errors about multiple declarations.  I tried to make a helper function in the main file called void drawToWindow(const Drawable& d) but it complained about that too, so I shortened it to drawToWindow(Drawable d) but it still complained.  I'm stumped on this one.  I really do not want to have to put all my rendering code into the main file, but I don't think I have a choice at this point.  Any help is appreciated.

[masskiller]

Try using it normally, it's placed that way in tutorials and most people's code for a reason. You actually have easy control of what's being drawn and have an easy notation, which is lost by trying to make a wrapper around it (kind of ironic). You can easily make wrappers around drawables and other stuff, but not so with a renderwindow due to how it works on SFML.

[Nexus]

Try using it normally, it's placed that way in tutorials and most people's code for a reason.

The reason why it is done like this in tutorials is simplicity, not scalability. However I doubt that a lot of experienced people have everything in main(), when it comes to developing a bigger project.

The sf::RenderWindow is rather stored in a separate class. Due to its multiple responsibilities (event handling, drawing), it may even be referenced in multiple classes. It is difficult to explain that in detail without delving into general design decisions. For example, one could have a class Renderer that holds a sf::RenderWindow member (possibly as a reference). Renderer then provides multiple draw() overloads, which take logical game objects as parameters, such as Player, Enemy, Scenery, etc. Internally, these are forwarded to sf::RenderWindow::draw() calls, which has the advantage of abstraction -- if you want to draw an enemy differently, just change that one function instead of searching every draw() call and finding out whether the passed sprite belongs to an enemy.

[masskiller]

The reason why it is done like this in tutorials is simplicity, not scalability. However I doubt that a lot of experienced people have everything in main(), when it comes to developing a bigger project.

Of course, I have a big project myself and I know handling it all in main is total madness, it totally goes against the purpose of OOP and other programming paradigms, but if you are still testing things and are nowhere near finishing your project it's better in my opinion to keep things simple until they truly do require some fancy solution.

[malachipclover]

The reason why it is done like this in tutorials is simplicity, not scalability. However I doubt that a lot of experienced people have everything in main(), when it comes to developing a bigger project.

Of course, I have a big project myself and I know handling it all in main is total madness, it totally goes against the purpose of OOP and other programming paradigms, but if you are still testing things and are nowhere near finishing your project it's better in my opinion to keep things simple until they truly do require some fancy solution.

It may make sense in some situations, but I know this project is going to expand rapidly, and so I would rather have things done right from the start than to do major refactoring work later on.  I think I will go with Nexus' idea of containing it within another class.  I like that and think it will do me well, plus it'll give me a reason to learn classes in C++, something I've been not looking forward to.  I don't know why though, because I started off with Java, and i immediately understood the concept of classes with very little explanation needed.  I guess it's just learning the syntax to them in C++ that I don't want to do.

[masskiller]

I don't know why though, because I started off with Java, and i immediately understood the concept of classes with very little explanation needed.  I guess it's just learning the syntax to them in C++ that I don't want to do.

It's simple in concept and it becomes incredibly practical once you get the handle of it, if your problem is not OOP, but C++ then I would suggest you go with a book right away, it will save you from many many headaches since the way Java handles things is very different (syntax-wise) to how C++ does it. The shift from Java to C/C++ is rather tough if you don't have the slightest idea of what you're doing.

I would first make classes for resource control and ease of handling drawables first. That will give you enough experience with C++ classes and possibly inheritance and polymorphism if you are willing to delve into it. Then do your window class after all that is done.

[didii]

Well I didn't read through all the comments, but the way I do it is to create a pointer to the sf::RenderWindow in every class so I have the possibility to change whatever I like in every class and I don't have to give the window through in every possible function I'm writing. So yeah, I still create the sf::RenderWindow in the main, but I do not have to handle the rest of it in the main class.

[malachipclover]

That might work too...  too bad I already started doing it with a renderer class