Laggy rendering.

[Nexus]

I'm sure Nexus and the others will have more to add to this, but that's what I know.

Actually, you summed it up very nicely
I've once made a list of common ownership semantics in C++, maybe that could also be helpful.

I officially have no idea what's wrong. I got rid of all dynamic_casts , used a map for fast retrieval and changed the raw pointers to the appropriate smart ones but the problem persists.

Yes. As I said before, a few dozens of operations per seconds won't degrade the performance, even if those are dynamic_casts. If you want us to help, you must reduce your code to a minimal example that shows the described behavior.

But be aware that FPS are not only affected by the application itself -- external factors like other processes, background tasks, anti-virus etc. may have considerable influence.

[Veritas]

I want to provide a minimal example but the classes are dependent on each other. The whole thing is not that big though, it's around 250 lines including includes and blank lines. I could post it if you guys feel it's not too much but otherwise I don't think I can further reduce the amount of code.

[Nexus]

I want to provide a minimal example but the classes are dependent on each other.

The idea of minimal examples is not to retain the original functionality, but rather to retain the problem. So, remove everything that doesn't contribute to your FPS issue, including class inter-dependencies.

Of course this takes some time, and now that you've installed the profiler, you could try to use it first.

[Veritas]

The profiler seems to be broken. I searched a bit and many others have the same issue with no apparent solutions. I will try to find something else. Anyway I will try to reproduce the problem, this seems too much for me to handle at the moment but I will get to it.

[Jesper Juhl]

UPDATE:

Managed to get gprof to work with codeblocks.  I don't think I am using the profiler correctly though, the file is missing the call graph and the times are 0 for everything. I have the -g and -pg flags enabled.

I've used gprof many times over the years and although it is not the best profiler around (I'd give that honor to Intel VTune) it does work.
Remember that you *must* use -pg both when compiling and when linking.
If you want you can send me your entire code in a private message and I'll take a look.

[Veritas]

After playing a bit with the profiler and if I read it correctly this appears to have to do with the typeid creations that take place when you want to fetch the components of every object in the update function. I will change the Systems interface so that the components will be cached. This should require more work for the user (will have to provide registration/unregistration functions) but hopefully the results will be worth it.

[Nexus]

After playing a bit with the profiler and if I read it correctly this appears to have to do with [...] hopefully the results will be worth it.

What does that mean? Why don't you measure with the profiler instead of playing around, guessing and hoping? You won't solve your problem by trying random things, you need a systematic approach.

I highly doubt that typeid is the performance bottleneck, especially if there are still only a few calls per second.

This should require more work for the user (will have to provide registration/unregistration functions)

That's a bad idea. Unless you can prove that this brings a real advantage, don't make the API inconvenient.

[Veritas]

It seems that this may have nothing to do with my engine. I made a very naive gameloop and the rendering still lags. Could this be a driver problem?

void World::run()
{
        sf::RenderWindow window(sf::VideoMode(1024, 768), "Testing");
        sf::RectangleShape sprite;
        sprite.setFillColor(sf::Color::Red);
        sprite.setSize(sf::Vector2f(100,100));
        sprite.setPosition(sf::Vector2f(0,0));
        sf::Vector2f delta;
        sf::Vector2f velocity;
        sf::Clock clock;
        sf::Event event;
        float elapsed;
        while(window.isOpen())
        {
                elapsed = clock.restart().asSeconds();
                velocity.x = 0;
                velocity.y = 0;
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
                {
                        velocity.x += -200;
                }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
                {
                        velocity.x += 200;
                }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up))
                {
                        velocity.y += -200;
                }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Down))
                {
                        velocity.y += 200;
                }
                delta.x = velocity.x * elapsed;
                delta.y = velocity.y * elapsed;
                sprite.move(delta);
                window.clear();
                window.draw(sprite);
                window.display();
        }
}

[select_this]

It seems that this may have nothing to do with my engine. I made a very naive gameloop and the rendering still lags. Could this be a driver problem?

Ignore my previous (deleted) answer, I didn't look at the code properly 

I ran your code and elapsed is nearly always smaller than 1/60.f so the majority of the time nothing will happen.

Here's a sample I got from running it:

Code: [Select]

Elapsed: 0.003635 1/60.f: 0.0166667
Elapsed: 0.002793 1/60.f: 0.0166667
Elapsed: 0.004756 1/60.f: 0.0166667
Elapsed: 0.003036 1/60.f: 0.0166667
Elapsed: 0.005751 1/60.f: 0.0166667
Elapsed: 0.004439 1/60.f: 0.0166667
Elapsed: 0.003327 1/60.f: 0.0166667
Elapsed: 0.008405 1/60.f: 0.0166667


[Veritas]

Edited for simpler example.
The elapsed time for me is 10 times bigger.

[select_this]

Yes that should be

elapsed += clock.restart().asSeconds();

I forgot to fix it after pasting.
The elapsed time for me is 10 times bigger.

The movement's pretty smooth on this computer (nb. not a high end machine by any means - dual core with integrated graphics).

You probably don't want to be testing for keypresses and setting the velocity in the while loop, so you might want to move that above the loop. Also, are you sure you want to be 'moving' the sprite repeatedly in the loop as well? It makes more sense to accumulate the distance for the sprite to move and then set the position afterward.

[Veritas]

This is simply a naive gameloop to demonstrate my problem. The rendering lags a lot for me.

[select_this]

This is simply a naive gameloop to demonstrate my problem. The rendering lags a lot for me.

I was just trying to eliminate possible bottlenecks; now that you've simplified your example, assuming the problem still persists, it looks like there's nothing there that would theoretically adversely affect performance (as I mentioned before, it runs perfectly smoothly on the computer I'm currently using).

[Veritas]

Hello everyone! It was a driver problem. I can't believe I spent so much time looking for code problems while it was a simple driver issue! Thanks a lot for your help and sorry for the waste of time!

[Nexus]

No problem. The time isn't wasted, I'm sure you've learned a lot of other useful things while trying to solve this issue.