Nothing is being drawn at the screen

[PauloSilvério]

I started to code a SFML project on Visual Studio Express 2013, i did some tests, everything was fine, then i started the real code and implemented a state manager, that also manages screen drawing, the RenderWindow variable is passed as reference to the draw function of my state manager, but nothing is being drawn.

I already did some tests, the current state is correct, and the texture is apparently being loaded correctly.

main.cpp:

#include <SFML/Graphics.hpp>
#include "statemanager.h"

int main()
{
        sf::VideoMode desktop = sf::VideoMode::getDesktopMode();
        sf::RenderWindow window(sf::VideoMode(desktop.width, desktop.height, desktop.bitsPerPixel), "Hunt and Explore", sf::Style::Fullscreen);
        window.setFramerateLimit(75);
        sf::View view(sf::FloatRect(0.0f, 0.0f, desktop.width, desktop.height));
        window.setView(view);
        StateManager* state_manager = StateManager::getInstance();
        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }

                window.clear();
                state_manager->draw(window);
                window.display();
        }

        return 0;
}
 

statemanager.h:

#ifndef STATEMANAGER_HEADERFILE
#       define STATEMANAGER_HEADERFILE
#       include <vector>
#       include <SFML/Graphics.hpp>

enum GAMESTATE
{
        GS_RUNNING,
        GS_PAUSED,
        GS_MAINMENU
};



class StateManager
{
        private:
                StateManager(){}
                GAMESTATE state;
                void changeState(GAMESTATE st);
                std::vector<sf::Sprite> loadedSprites;
                std::vector<sf::RectangleShape> loadedRects;
                sf::Image test;

        public:
                static StateManager* getInstance()
                {
                        static StateManager* inst;
                        if (inst)
                                return inst;

                        inst = new StateManager();
                        inst->changeState(GS_MAINMENU);
                        return inst;
                }
                bool draw(sf::RenderWindow& w);
};

#endif
 

statemanager.cpp:

#include "statemanager.h"

void StateManager::changeState(GAMESTATE st)
{
        state = st;
        switch (state)
        {
                case GS_MAINMENU:
                {
                        sf::VideoMode dkt = sf::VideoMode::getDesktopMode();
                        sf::RectangleShape rshape(sf::Vector2f(dkt.width, dkt.height));
                        rshape.setPosition(sf::Vector2f(0, 0));
                        sf::Texture texture;
                        texture.loadFromFile("data/mainmenu/bg.png");
                        texture.setSmooth(true);
                        rshape.setTexture(&texture);
                        loadedRects.push_back(rshape);
                }
                break;

                case GS_PAUSED:
                        break;

                case GS_RUNNING:
                        break;

                default:
                        break;
                }
}

bool StateManager::draw(sf::RenderWindow& w)
{
        switch (state)
        {
                case GS_MAINMENU:
                        w.draw(loadedRects.back());
                        break;

                case GS_PAUSED:
                        break;

                case GS_RUNNING:
                        break;

                default:
                        break;
        }
        return true;
}
 

Thanks in advance

[Hapax]

http://www.sfml-dev.org/tutorials/2.3/graphics-sprite.php#the-white-square-problem




Is this a Singleton? I've been trying to identify what they are for a long time (so to avoid using them) and this is the first thing I've seen that I would think qualifies as one.
Which brings me to a question: why can't you just create an object instance of StateManager, rather than pointing all over the place using raw pointers, and then do the initialisation in the constructor, rather than your getInstance and changeState methods?

[PauloSilvério]

Yeah, that's a Singleton, but why do you avoid them?

I'm using it because the statemanager object need to be the same all over the code, and it's better to manage it that way instead of using a single static global object, it avoid a lot of linking problems too, I'm using the changeState method because i want to clean and load the sprites and shapes vectors on scene and state changes, so it appeared to be a nice way to do that.

I understood the problem, partially, but i don't know how to fix it, can it be fixed without compromising the actual design and logic of my code? Or I'll need to change it all to fit how SFML works?

edit: i could implement a map using texture as key instead of the vector approach, but is that the correct way? aren't maps a lot slower than vectors?

[PauloSilvério]

Ok, i tried the map thing in a lot of different ways, still don't work...

[eXpl0it3r]

There's absolutely no reason to use a singleton in this (and nearly every other) scenario. Create one instance on the stack and be done with it.

As for the issue with the texture getting destroyed before you can actually draw something with it, you could use some form of resource holder as described in the SFML Game Development book or the Thor library.

For my projects I implement the state machine with each state being its own class and pretty much forget about the whole switch-case listing, here's an example.

[kitteh-warrior]

Just to add on to what others have said:
This:

(click to show/hide)

{
    sf::VideoMode dkt = sf::VideoMode::getDesktopMode();
    sf::RectangleShape rshape(sf::Vector2f(dkt.width, dkt.height));
    rshape.setPosition(sf::Vector2f(0, 0));
    sf::Texture texture;
    texture.loadFromFile("data/mainmenu/bg.png");
    texture.setSmooth(true);
    rshape.setTexture(&texture);
    loadedRects.push_back(rshape);
}

is in it's own scope. As Hapax already said, this is the problem. At the end of the scope, the newly declared sf::Texture "texture" is destroyed.
Also, see this for why singletons are bad.

[Hapax]

Yeah, that's a Singleton, but why do you avoid them?

it's better to manage it that way instead of using a single static global object

Singleton is a single static global object...

i don't know how to fix it, can it be fixed without compromising the actual design and logic of my code?

I figured out a way to 'fix' your (current) problem by adding a single word to your code but I'm not sure if encouraging this design would actually be helpful.

[PauloSilvério]

I figured out a way to 'fix' your (current) problem by adding a single word to your code but I'm not sure if encouraging this design would actually be helpful.

That's arrogant as fuck, there is literally no reason to don't use singleton, seeing programmers acting like webdesigners is REALLY depressing.

One guy saying "this book says it's good, but my book says it's bad, my book is what's being used by modern programmers, don't you want to be modern like me?" isn't a real argument, the others arguments don't apply to the case, guys, come on, let's think a bit instead of letting others think for you. There is literally NONE technical reason for not using singletons on this case AFAIK, and you guys didn't pointed none.

But thanks for the real solutions on the subject, i appreciate it, really.

[eXpl0it3r]

One guy saying "this book says it's good, but my book says it's bad, my book is what's being used by modern programmers, don't you want to be modern like me?" isn't a real argument, the others arguments don't apply to the case, guys, come on, let's think a bit instead of letting others think for you. There is literally NONE technical reason for not using singletons on this case AFAIK, and you guys didn't pointed none.

You are aware that you're doing exactly what you said one shouldn't do ("I'm right because, I say so"), right?

There are reasons to use a singleton, your posted code is not one of them.
Both here on the forum (it's not the first time the discussion has emerged) or else where on the internet you can find all the technical arguments on when singletons can be used and why they are nearly never needed nor a good idea to begin with.

Also while this community likes to give advice on how to write better/modern/nicer/maintainable code, it's only a "side-effect" and not what the SFML forums are here for, as such community members often don't provide all the possible links and explanations on these topics, but rather hope that one would reflect on the code and research a bit more on the topic.

Above all don't forget that we're trying to help. We really don't want to offend or insult people and I'm really sorry if things come across like that, it's really not the intend.

[Jesper Juhl]

there is literally no reason to don't use singleton,

Well, we disagree.
Here are some links to some argumentst against (and more can easily be found):

 http://en.sfml-dev.org/forums/index.php?topic=18224.msg131147#msg131147

 http://www.sfml-dev.org/faq.php#prog-singleton
 

[Hapax]

@PauloSilvério
I actually said "I'm not sure" if it would be helpful or not. Nothing arrogant about that but still...

Fine, go ahead. I'll leave the judgement of whether to use it or not up to you. Have fun:

Change

sf::Texture texture;

to

static sf::Texture texture;

Good luck.

[PauloSilvério]

there is literally no reason to don't use singleton,

Well, we disagree.
Here are some links to some argumentst against (and more can easily be found):

 http://en.sfml-dev.org/forums/index.php?topic=18224.msg131147#msg131147

 http://www.sfml-dev.org/faq.php#prog-singleton
 

I understand that, but that's not the case, first because my singleton lifetime is the lifetime of the application, and second because even without a singleton, or a normal global static object, the class couldn't be decoupled from the whole application.

@PauloSilvério
I actually said "I'm not sure" if it would be helpful or not. Nothing arrogant about that but still...

Fine, go ahead. I'll leave the judgement of whether to use it or not up to you. Have fun:

Change

sf::Texture texture;

to

static sf::Texture texture;

Good luck.

Oh... That... Not a good solution, it would be a nightmare to destroy every texture instance created on the right time.

I already found what i think is a good solution, just created another vector to contain textures, this will add a little bit more of work but i think it's fine for now.

Thanks guys.