Messages

1

General / Re: sf::Window::draw

« on: March 22, 2016, 05:42:04 pm »

Thank you for fast reply.

For the background we use one big image, like 2000x3000 pixels but I'll think about dividing it into smaller parts, if it would help. I'll also use quadtrees for checking collision in more efficient way, because now I am able to check up to 600 collisions in one loop transition and I need like 1700.

2

General / sf::Window::draw

« on: March 22, 2016, 04:12:16 pm »

Hi all,

I'm making a game with quiet big rooms with many NPCs and other stuff in them that need to be displayed while playing. This makes a huge number of calling sf::Window::draw() method. To be able to handle such vast spaces I also use sf::View and show only a small piece of that room. And here is my question: how much does it cost to call sf::Window::draw() and would checking every sprite if is it in my view's range be reasonable (won't costs of checking it be bigger than just drawing sprites invisible at the moment)? Or maybe it's already done in SFML, that if something isn't visible it isn't drawn? I try to make my code less expensive.

Thank you in advance for all answers and discussion!

3

Audio / Re: Unable to add a sf::Sound object to a map

« on: February 10, 2016, 10:43:17 am »

Thank you Hapax. I didn't know it's working that way. I'll immediately check if it solves my problem and post if it doesn't.

In your code, you create a temporary sound buffer, load the sound sample from a file (without testing to see if it fails), then assign it to the new sound object.

I chcek if it fails, I only didn't want to show too much code to keep it clear

4

Audio / Unable to add a sf::Sound object to a map

« on: February 10, 2016, 12:57:03 am »

Hi all,

I'm using this code for handling sf::Texture objects and it works almous fine so far.

        Texture & Textures::add(const string & name, const string & directory)
        {
                map<string, Texture>::const_iterator it = tekstures.find(name);
                if (it != textures.end())
                        return textures.at(name);

                Texture tex;
                tex.loadFromFile(directory);
                textures[name] = tex;

                return textures.at(name);
        }

And I tried doing this:

        void Sounds::add(const string & name, const string & directory)
        {
                map<string, Sound>::const_iterator it = sounds.find(name);
                if (it != sounds.end())
                        return;

                SoundBuffer buffer;
                bufor.loadFromFile(directory);
               
                Sound sound;
                sound.setBuffer(buffer);
                sounds[name] = sound;   // here I get Runtime error
        }

The Runtime Error I get says

Expression: map/set iterator is not incrementable

How can I solve it?

5

Graphics / Re: sf::Texture and sf::Text colliding?

« on: February 09, 2016, 08:51:59 pm »

Ok, I worked on my code and figured out, where EXACTLY the error occures. Forget, please, about those sf::Text objects, most of them, if now all, are innocent. The problem lays in that code:

void Engine::load(int & lvl)
{
        EnterCriticalSection(&critical_section);
        loaded = 0;     // an integer variable incremented after every call
        LeaveCriticalSection(&critical_section);

        load_voices();
        EnterCriticalSection(&critical_section);
        loaded++;
        LeaveCriticalSection(&critical_section);

        load_textures();
        EnterCriticalSection(&critical_section);
        loaded++;
        LeaveCriticalSection(&critical_section);

        //so on
}

void Engine::set_up(int & lvl)
{
        if (!InitializeCriticalSectionAndSpinCount( & critical_section, 0x00000400))
                return;

        thread loading_thread(&Engine::load, this, lvl);

        srm::Manager::add("Loading screen", "loading_screen.png");

        Sprite spr;
        spr.setTexture(srm::Manager::resolve("Loading screen"));

        Text procent;
        procent.setFont(Texts::menu_font);
        EnterCriticalSection(&critical_section);
        procent.setString(loaded);
        LeaveCriticalSection(&critical_section);
        procent.setPosition(200, 200);
        procent.setColor(Color::Blue);
        procent.setCharacterSize(20);

        while (!thread)         //indicates, whether loading_thread still works
        {
                Event events;
                Vector2f mouse(Mouse::getPosition(window));
                while (window.pollEvent(envents))
                {
                        if (events.type == Event::Resized)
                                window.setSize(window_resolution);
                }

                EnterCriticalSection(&critical_section);
                procent.setString(loaded);
                LeaveCriticalSection(&critical_section);

                window.clear();
                window.draw(spr);
                window.draw(procent);   //this causes the error I get
                window.display();
        }
        loading_thread.join();

        DeleteCriticalSection( & sekcja_krytyczna);
}
 

So basicly when I comment out that line, that causes the Runtime Error it doesn't appear. I'll say it again: first attempt to call method Engine::set_up() is always succesful, second attempt always causes an app crash. Can you solve it?

6

Graphics / Re: sf::Texture and sf::Text colliding?

« on: February 09, 2016, 12:14:26 am »

Well, thank you all for responses.

Nexus, I've heard of thor, however my team don't want to learn it, so I stuck and I tried to make my own texture manager (SoundBuffer and maybe Text managers were also planned) but I got that runtime error and it stopped me for a while.

I'll give my Manager a few more chances, changing some other parts of code and probably, if it doesn't help, use thor.

There is still a mystery, why method, that should have no real impact on any Text object, causes a bug but moving it to the constructor makes the code work again Solve this, if you can, I have no idea, what is going on there

7

Graphics / sf::Texture and sf::Text colliding?

« on: February 08, 2016, 12:35:30 am »

Hi all,

I had a working project that was about 4000 lines of code, already using many sf::Texture and sf::Text objects. Then I decided that I need a texture manager to optimize loading many files. Here is the code:

//Declarations

class Manager
{
private:
    static map<string, Texture > textures;
public:
    static Texture & add(const string & name, const string & directory);
    static Texture & resolve(const string & name);
};

//Definitions

Texture & Manager::add(const string & name, const string & directory)
{
    // Check, whether a said texture was already maped
    map<string, Texture>::const_iterator it = textures.find(name);
    if (it != textures.end())
    {
        cout << "Said element was loaded" << endl;
        return textures.at(name);
    }

    // Adding a new texture
    Texture tex;
    tex.loadFromFile(directory);
    textures[name] = tex;

    cout << "Texture added" << endl;
    return textures.at(name);
}

Texture & Manager::resolve(const string & name)
{
    cout << "Resolved" << endl;
    return textures.at(name);
}

map<string, Texture > Manager::textures;
 

And I wanted to test it so I replaced this:

void Engine::set_up(int & lvl)
{
    Texture texture;
    texture.loadFromFile("data/loading_screen.png");
    Sprite spr;
    spr.setTexture(texture);

    // ...
}
 

with this:

void Engine::set_up(int & lvl)
{
    srm::Manager::add("Loading screen", "data/loading_screen.png");

    Sprite spr;
    spr.setTexture(srm::Manager::resolve("Loading screen"));

    // ...
}
 

What happened: this is the loading screen. So I pressed "PLAY". Everythink worked, the loading screen appeard, level has been loaded. I got back to main menu and pressed "PLAY" again. And now, for some reason, I get Runtime Library Error: http://ifotos.pl/z/sexsqph. I tought it is caused by new code. But when I tried to debug, it turned out that my game stops on setting sf::Text objects. Random one, to be precised, in random method, some times in the Engine::set_up() method, sometime in other methods. And I am confused. It looks that these are colliding.

What's more, when I moved srm::Manager::add() calling to the constructor of Engine class, everything works fine again
(it looks like this):

//Constructor
Engine(){ srm::Manager::add("Loading screen", "data/loading_screen.png"); }

//Method
void Engine::set_up(int & lvl)
{    
    Sprite spr;
    spr.setTexture(srm::Manager::resolve("Loading screen"));

    // ...
}
 

So can you explain me, whats going on in my project? I don't understand why it's behaving like this? How can I improve my code to make it working perfectly? Thank you in advance!

8

Graphics / Re: Capturing window content

« on: December 23, 2015, 07:31:44 pm »

I just thought loadFromFile = draw in some way.

9

Graphics / Re: Capturing window content

« on: December 23, 2015, 04:36:44 pm »

Huh, seems logical. For some reasons I didn't thought about creating one before drawing to it. I just treated it like sf::Texture, where there is no need to pass any size of what we want to store in it, like calling sf::Texture::loadFromFile() method. Thank you now it works perfectly.

For all, who could have any problem like that in the future, you need to call sf::RenderTexture::create() for sf::RenderTexture object before drawing to it:

if (!cut_scene)
{
    RenderTexture texture;
    texture.create(500, 500);    // This line is NECESARY, you should change the values of course ;)
    texture.clear();
    texture.setView(view);
    texture.draw(stuff_1);
    texture.draw(stuff_2);
    texture.draw(stuff_3);
    texture.display();
    cut_scenes.run(texture);
    cut_scene = true;
}

Thank you again, you gave me another lesson about SFML

10

Graphics / Re: Capturing window content

« on: December 23, 2015, 12:53:04 am »

Thank you for your fast reply!

I tried sf::RenderTexture and now no error occures. Athough nothing is being displayed. This is how my code looks like now:

if (!cut_scene)
{
    RenderTexture texture;
    texture.clear();
    texture.setView(view);
    texture.draw(stuff_1);
    texture.draw(stuff_2);
    texture.draw(stuff_3);
    texture.display();
    cut_scenes.run(texture);
    cut_scene = true;
}

The declaration of run() method:

cut_scenes.run(RenderTexture &);

11

Graphics / Capturing window content

« on: December 22, 2015, 11:52:36 pm »

Hi all!

I'm having a problem, maybe an easy to solve one, nevertheless I can't find any working solution.

I want to capture whole window content, pass it to another method and display as background. At first I tought about

sf::Image

class so I created an object and tried to get what's on the screen. But even though one cycle of rendering stuff from the game passed all I got captured was the loading screen. I started some research and found out it's not the best option, because it's slow. OK then, I wrote Sleep(5000); over the capturing call and it didn't helped at all. But then I used more recommended code which is

sf::Texture::update();

Now it's worse, because I get that error:

Assertion failed: x + window.getSize().x <= m_size.x, file D:\sfml-release\_Sources\SFML\src\SFML\Graphics\Texture.cpp, line 407

Fine. There were thousands of errors in my life, aint one like that. I googled it and I found it might be some problem with including *.dll files to my project. So I checked all of them, for debug as well as release version and didn't find any mistake. Now I'm desperate, this is my code:

if (!cut_scene)
{
        Texture tex;
        tex.update(window);
        cut_scenes.run(tex);
        cut_scene = true;
}

When I change the line with updating texture with window content to loading to the texture a file it works perfectly.

I'm sorry, if this error is easy to fix but I really googled much and found nothing helpful. I'm also sorry for my english, which is probably awful.

Thank you in advance for help.

12

Graphics / Re: Overriding sf::Drawable::draw

« on: October 28, 2015, 09:12:22 pm »

Now I'm like John Snow; I know nothing.

I was tired of keeping trying to make that code work. As I wrote yesterday, I've made some changes and compiled the project. Once again I saw white squares and as I had a hard day I haven't time to write code. Today I entered the forum, saw your post and tought "Great idea, let's see how it works!". So I, making no changes from yesterday, debugged code and started a "new game". Everything was set up in it's place, displayed fullly properly. I have no idea why it didn't worked yesterday 

All in all thank you all for your time you spended here reading my sh*tty code and trying to help me. Now I know more about SFML and object oriented programing in C++. Thakns to you I started reading some more materials about both and I find it really helpful so far.

The solution to the problem for all that could look for this in the future:
1. Ensure that you don't move your Texture objects in memory after calling sprite.setTexture(texture);.
2. If you do you can do two things:
    a) change the code to don't move the Texture
    b) change the code to call sprite.setTexture(texture); always right after moving the Texture

In my opinion the case is closed, if I had some problems with it in the future I'll probably be able to handle with it on my own (thanks to you ofc ).

You guys are awesome! Thank you once again for what you did for me, for your patience and nerves

Best regards,
Skorpion

13

Graphics / Re: Overriding sf::Drawable::draw

« on: October 27, 2015, 10:49:55 pm »

1. Use a texture manager, so that texture are managed and stored elsewhere and remain at the same location in memory, regardless of how you use them.

Is that something that is built-in in SFML or should it be a class wrote by myself?

SFML doesn't have it, but Thor does, as I mentioned earlier. You said you wouldn't want to use another library, but when you're considering yourself a beginner in these things, it may not be the best idea to write such a class from scratch

If it relays on me are there some other ways better than std::vector, std::list (which you metnioned in point 3 as not the best idea) and reallocing tables?

You could use an associative container like std::map, and refer to the texture using some identifier (the key in the map). That's also a part of what thor::ResourceHolder does, it just simplifies many things on top of that.

The problem is more complex, I don't write it alone But I'll try to convince our engraver to make one tileset for level, that would be more efective and simplify many things (Now I'm so smart, when you told me all that things )

But then, do they finaly stand still at one place, that I could call spr.setTexture(tex); when nothing else would be pushed to the vectors or is it still possible, that dusring executing my programm vector would be moved moved (not intentionaly by me)?

If you don't touch the vectors themselves, it's only possible if the object of the surrounding class (which contains the vector) is moved/copied.

Strange. I did it like I said, first made everything up, then called spr.setTexture(); and from then on never touched any vector or whole object. Still didn't worked.

And don't apologize for your English in every post, it's not that bad

"it's not that bad" = still not perfect = still ther's something to apologize for, because it makes reading harder and I'm not an easy interlocutor; I write long posts and ask stupid questions

14

Graphics / Re: Overriding sf::Drawable::draw

« on: October 27, 2015, 07:44:10 pm »

When you call sprite.setTexture, the sprite stores the address of (pointer to) the texture object. So if you copy or move the texture around, the address stored in the sprite becomes invalid and all you get is a white square instead of the texture data.

At fitst I would like to thank you for briliant post with many useful informations for me. Now I see how much do I have to learn still to use C++ fluenltly. Thank you again. Still, as I'm qiuet noob in programing I have a few questions to you but I feel I'm beginning to understand what happens when my code is executed. That seems and for sure is really important.

(...)
So there are usually three solutions to this problem:

1. Use a texture manager, so that texture are managed and stored elsewhere and remain at the same location in memory, regardless of how you use them.

Is that something that is built-in in SFML or should it be a class wrote by myself? If it relays on me are there some other ways better than std::vector, std::list (which you metnioned in point 3 as not the best idea) and reallocing tables?

2. If you don't need to share textures (ie. one texture, one sprite) then the class that encapsulates them needs to handle copy/move operations properly. When you copy an instance of a class that holds a sprite and its texture, both are copied, and the sprite copy needs to use the texture copy, not the original texture (as its the case by default). So you need to write the code that does it, in the copy/move constructor and copy/move assignment operators. If you let the compiler generate the copy/move code for you, it will be wrong, the sprites will end up pointing to texture objects that don't exist anymore.

As my code looks now like this:

class CLASS
{
    struct 1
    {
        Sprite spr;
        Texture tex;
    }
    struct 2
    {
        Sprite spr;
        Texture tex;
    }
    struct 3
    {
        vector<1> one;
        vector<2> two;
    }
    vector<3> map;
}
 

Would it work, when I'm never touching those vectors after reading textures from file, if I matched sprites to the textures after reading last one thing at all into vector? I mean at first I read textures, other stuff, create some other variables and push everything to the vectors. The vectors are moved in memory a few times during that reading and creating variables. But then, do they finaly stand still at one place, that I could call spr.setTexture(tex); when nothing else would be pushed to the vectors or is it still possible, that dusring executing my programm vector would be moved (not intentionaly by me)?

3. Make sure that no copy or move ever happens, by reserving space in your vector or using containers that don't invalidate their elements (std::list). I don't like this approach, I don't consider it a clean solution (or a solution at all) to this design problem.

Well, that was what I liked most when I read all 3 your propositions But if you say it is bad...

Thank you for fast replay and I'm sorry for my english.

15

Graphics / Re: Overriding sf::Drawable::draw

« on: October 27, 2015, 05:10:56 pm »

This is explain in the initial tutorials.

I read it 'till the end of "Ok, can I have my Sprite now" and gave up as I didn't found what I was looking for

You gave up when you got to "The White Square Problem" when because you didn't find the information on the problem that you are having with a white square?

I read the "Ok, can I have my sprite now?"and then gave up, the "The White Square Problem" is under it and I didn't saw it. Other words I read everything 'till end of "Ok, can I have my sprite now?" and closed the tab.

I don't understand how exactly the sprites work. As these objects have a pointer to the texture then why when I store my textures in std::vector, then call sprite.setTexture(textures_in_vector[4]); it doesn't work properly? Is it I can't have a pointer to something that is stored in a vector and the class Sprite has a pointer so the value the pointer is indicating to is unreachable?

Sorry for my english.