Messages

1

SFML projects / Re: [2D Platformer] Melting Saga

« on: April 04, 2016, 09:24:58 am »

Hi! I was wondering how did you implement the updater. The game looks neat btw. 

2

General / Re: Fixed timestep CPU usage

« on: February 13, 2016, 11:29:07 am »

Seems like I missunderstood the usage of a fixed timestep. Thank you guys for your help! 

3

General / Re: Fixed timestep CPU usage

« on: February 12, 2016, 11:44:28 pm »

So basically, the fixed timestep is just for a smooth update method and eventually smooth rendering by interpolating?

4

General / Fixed timestep CPU usage

« on: February 12, 2016, 11:34:16 pm »

Hello. I have implemented a fixed timestep. The problem with this is that my CPU usually goes to about 30-40% and I don't understand why. A solution would be to just use the setFramerateLimit method or vsync, but I don't understand why would I need a fixed timestep if I use one of those. If someone can shed some light here that would be much appreciated.

const sf::Time m_frameTime = sf::seconds(1.f/60.f);
sf::Clock clock;
sf::Time passedTime = sf::Time::Zero;

while (window.isOpen())
{
        sf::Time elapsedTime = clock.restart();
        passedTime += elapsedTime;

        while (passedTime > m_frameTime)
        {
                passedTime -= m_frameTime;

                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
                update(m_frameTime);
        }
               
        window.clear()
        window.display();

}

5

General / Re: display variables

« on: September 07, 2015, 08:48:44 pm »

You don't seem to know what you're doing. 

6

General / Re: display variables

« on: September 07, 2015, 08:41:43 pm »

Dude you should really get a c++ book and actually read it before getting into SFML.

DisplayedScore.setString(Score_str);

7

Graphics / Re: SFML Access violation

« on: August 24, 2015, 10:56:56 pm »

I can't really tell what's the actual problem without being able to see more of the code...

8

Graphics / Re: SFML Access violation

« on: August 24, 2015, 10:21:42 pm »

Try this code:

texture1 = new sf::Texture();

And in main:

Game game;

Also you should avoid using raw pointers whenever possible. If you absolutely need to use them then take a look at the smart pointers.

9

General / Re: Memory management

« on: August 23, 2015, 02:51:06 pm »

This would be a fast fix using this loop:

for (unsigned int i = 0; i < states.size(); i++)

Yes. The other loops are looking like the one above.

10

General / Re: Memory management

« on: August 23, 2015, 02:38:38 pm »

Is your error compile-time or run-time? Are you trying to erase any elements while iterating?

Run-time. I read about trying to erase elements while iterating gives an error. But all I do is clear the vector. 

Also, before iterating through the vector I check if it is empty or not:

if (!states.empty())
{
        for (it = states.begin(); it != states.end(); ++it)
        {
                (*it)->update(window, dt);
        }
}

11

General / Re: Memory management

« on: August 23, 2015, 02:12:16 pm »

I declared an iterator in my header file and after I push back a state inside the vector I reset the iterator like this:

Why do you declare an iterator in a header? Is it global?

Iterators are objects of extremely local scope. In most cases, it's an error to store them -- they're used for iteration, and they become invalid as the underlying container changes.

for (it = states.begin(); it != states.end(); ++it)
{
    (*it)->update(window, dt);
}

Don't do that! Declare the iterator locally, that is, inside the for loop.
Or use range-based for loops directly.

If I declare it locally (inside that method only) I get a vector iterator not incrementable error. The same goes for the range-based for loop.

I could get this to work without using an iterator like this:

for (unsigned int i = 0; i < states.size(); i++)
{
    states[i]->update(window, dt);
}

Or with the iterator, but it must be declared in the header file or in the cpp file outside of the methods because I have to reset it after I clear the vector and push_back another state:

states.push_back(std::move(state));
it = states.begin();

12

General / Re: Memory management

« on: August 23, 2015, 02:01:14 pm »

Thank you for the advice!

I cannot use the range-based for loop since the iterator must be updated. I tested this out, when I try to enter the PlayState for example, I get an error when the state is getting pushed back: Vector iterator not incrementable. The only way for this to work is to use:

for (auto i = 0; i < states.size(); i++)

Or:

for (auto it = states.begin(); it != states.end();  ++it )

EDIT: The second for loop gives the same error as the range-based. So the first for is the only one that's working.

Would you mind giving some context to this error? Because that's no supposed to happen.

It's strange  . I got it working though.
I declared an iterator in my header file and after I push back a state inside the vector I reset the iterator like this:

states.push_back(std::move(state));
it = states.begin();

Then I can use this for without any errors:

for (it = states.begin(); it != states.end(); ++it)
{
        (*it)->update(window, dt);
}

13

General / Re: Memory management

« on: August 22, 2015, 10:23:32 pm »

I though it would be cool to use a transparent splashscreen.

http://en.sfml-dev.org/forums/index.php?topic=18217
http://en.sfml-dev.org/forums/index.php?topic=13904
http://en.sfml-dev.org/forums/index.php?topic=17947
http://en.sfml-dev.org/forums/index.php?topic=18337
http://en.sfml-dev.org/forums/index.php?topic=16776

These should help 

I actually used texus' code for the splashscreen class. (it's inside the github repo I posted earlier)

14

General / Re: Memory management

« on: August 22, 2015, 08:44:47 pm »

I was aiming for window transparency.

Why exactly would you want to do that?

I though it would be cool to use a transparent splashscreen.
If I ever need my program to be cross-platform, I'll find another solution or simply delete the class.

But preferably, lay off the use of dynamically-allocated memory.

Well, I kind of need pointers in my case because the State class is an abstract class and I read that references are not recommended (?). I find std::unique_ptr to be the best solution for me ATM since it can take care of the clean-up itself and the vector will be the only one that can access it once it is moved.

2. Prefer for (std::unique_ptr<State>& state : states) { ... } to for (int i = 0; i < vec.size(); i++) { ... }.

I cannot use the range-based for loop since the iterator must be updated. I tested this out, when I try to enter the PlayState for example, I get an error when the state is getting pushed back: Vector iterator not incrementable. The only way for this to work is to use:

for (auto i = 0; i < states.size(); i++)

Or:

for (auto it = states.begin(); it != states.end();  ++it )

EDIT: The second for loop gives the same error as the range-based. So the first for is the only one that's working.

15

General / Re: Memory management

« on: August 22, 2015, 07:57:10 pm »

What you could possibly do instead is add some pause and resume functions to your state, and give your states access to your state manager (pass a reference on each function call). What this could allow you to do is check if the newest state is an inventory state (via using dynamic_cast on it's pointer), and rather that halting the gameplay (which you could do if the state is something else), you could call some special function your inventory state has to pass a reference to your in-game state and have your inventory manually update your in-game state itself, but under special conditions (such as disabling input to your player while in the inventory menu, darkening things around the inventory menu, or whatever).

That's an interesting idea, thanks for sharing I will look into it!

I'm not sure exactly what your goals were

I was aiming for window transparency. Sorry if what I said earlier wasn't clear enough. Basically I know that SFML can't do that (correct me if I'm wrong) so the only solutions I had at the moment were using OpenGL or win32.


So, going back to the std::unique_ptr.
Basically if I have this method:

void foo(std::unique_ptr<int> a, std::unique_ptr<int> b);

I should use one of the following:

foo(std::unique_ptr<int>(new int(5)), std::unique_ptr<int>(new int(42)));
foo(std::make_unique<int>(5), std::make_unique<int>(42));

Is that what you were trying to say?