1) That's interesting. When I went on SFML I clicked download current version. Does that happen to be 1.6? I shall update!
Yeah, it's unfortunately a miss communication (see
here).
2) So shall I create an imageHolder (or something) class (or struct, which would be better?) that contains instances of all images?
Well it really depends on your project. In small projects where I didn't really needed to share the textures between states, I simply declared the textures as member variables of the state and used it directly. But if the project grows a bit then you might want to implement a resource manager. There are examples on the GitHub wiki or you can take a look at what Thor provides.
3) Yes, but the init function takes arguments. I don't think constructors can take arguments. Is it a better idea to just use a ton of getter and setter functions?
Ehrm, maybe you should go back again to a C++ book or similar. Of course constructor can take arguments! You can even overload them, etc...
4) Elaborate?
This is better...
void foo(sf::RenderWindow& window)
{
// ...
}
... than this ....
void foo(sf::RenderWindow* window)
{
// ...
}
5) Ok, I shall provide code. I was avoiding doing that because i'd have to strip down a ton of unrelated stuff from the main.cpp and the enemy.h and enemy.cpp and stage.h and stage.cpp, which would take some time since they're all huge, and I wanted to avoid taking this much time if by any chance it wasn't necessary.
Everything has its cost...
Also if they are that huge, then you should think about splitting them up/getting a better code design.
6) Also, forgive me, I'm a nooblet at C++, but I have quite a bit of Python experience which is much easier 
Sure things, but also keep in mind that C++
can't be learned by the trial-and-error principle, it's just too complex to go that approach. IMHO one just has to read a
good book about C++ to really understand what one is doing...
7) Code below
http://pastebin.com/712QvpdA
(Keep in mind that this is not really called 'minimal' code...
)
As I said, if the memory location of the sf::Image changes the references the sprites hold get invalid. This happens every so often when you push_back() enemies on the vector. A vector guarantees to have the memory laid out contiguous, which means that when the vector size grows it has to relocate all elements to a new place in memory to guarantee the contiguous of the elements layout.
The solution? As I said, don't pair sprites and images/textures. It's okay to copy around sprites but it's not just okay to copy around textures.
If you ever work with a vector of textures you should probably use
std::vector<std::unique_ptr<sf::Texture>> or at least pre-allocate the number of elements you want to use.
I would greatly appreciate if you give tips on how I could improve this, and the design of the whole thing.
I won't write an essay on it, since it's a huge topic and needs often some intuition that can't just be taught... The best thing you could do, is look at already existing and open source projects to see how things where handled there...
