Problem with choppy/laggy/jerky scrolling in SFML2 (binary inside)

[waxx]

Hi guys

I've been coding my next game - a runner - for couple of weeks and yet I can't seem to handle the problem I have with it. It runs like shit. Now, I don't believe I'm doing anything wrong performance wise, as simple one sprite scrolling slowly on screen feels choppy on its own. And in dynamic game like mine it really is annoying. I don't know what to do - in case it's only my weird feeling I'm throwing out here a test binary (controls: Z jump X attack), try it for yourself:
https://dl.dropbox.com/u/9649932/Release.rar

Looking forward to some feedback and tips.

[eXpl0it3r]

Looks nice!

It seems you've implemented a bad way to calculate the physics. You should take a look at this article.

But without code we can't really help you...

[waxx]

Well... I'm basically not even using any delta time nor anything, capped FPS with VSync and left it like that. Should fixed timestep actually fix it?

[eXpl0it3r]

Well... I'm basically not even using any delta time nor anything, capped FPS with VSync and left it like that.

Then you're doing something quite wrong in your calculations...
Also keep in mind that this can be quite a bit 'dangerous', because SFML can't guarantee that VSync gets activated, because one usually can force VSync on/off with the driver.

Should fixed timestep actually fix it?

Probably not, since it's a problem in your math (I guess), but it's better in any case.

[waxx]

//pseudocode
speed = 0.05f;
pos -= speed;

drawAt(clouds, pos);

how's that my math's problem?? simple thing like this already makes the thing damn laggy

[eXpl0it3r]

And again, without code we can only guess.

[waxx]

I just gave you the code.

[eXpl0it3r]

I just gave you the code.

Where? That little pseudo code you mean?
As you've noticed on your own, it 'probably' won't be the cause, thus we need to see a complete and minimal example that reproduces the problem. Which means that you have to narrow down the problem, while minimizing the codebase. If you do that you also don't have to fear any code 'stealing' or whatever are your reasons for not giving more information in the first place...

[waxx]

zzzzzzzz

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1024, 600), "SFML works!? No");
        window.setVerticalSyncEnabled(true);
        sf::Vector2f pos(0,0);
        sf::Vector2f pos2(2048,0);
         sf::Texture img;
     img.loadFromFile( "test.png" );
         img.setSmooth( false );

    while (window.isOpen())
    {

        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
               
                pos.x -= 0.5f;
                pos2.x -= 0.5f;
               
                if(pos.x + 2048 < 0)
                        pos.x = pos2.x + 2048;
                if(pos2.x + 2048 < 0)
                        pos2.x = pos.x + 2048;

                sf::Sprite sr(img);
                sr.setPosition(pos);
               
                sf::Sprite sr2(img);
                sr2.setPosition(pos2);

                window.clear(sf::Color::Yellow);
        window.draw(sr);
        window.draw(sr2);
        window.display();
    }

    return 0;
}

Test asset: https://dl.dropbox.com/u/9649932/test.png
How to test: compile and run, stare at it literally for 30-60seconds, focus please, and tell me whether the movement is fluid and smooth as toddler's arse or choppy and jerky for whatever reason

[cire]

It is perfectly smooth here.

[eXpl0it3r]

Yep works fine here too, while the release binary has problems...

Have you ever run any performance test on your update function, is it at all time <= 1/60 of a second?

[waxx]

But even the sample I just gave you feels meh to me. Are you guys running it with static or dynamic libs?
And my PC is high-end.

[krzat]

Disable vsync a try higher fps.

[eXpl0it3r]

But even the sample I just gave you feels meh to me.

Well 'meh' isn't really something we can go with.
For me there's a huge difference between the release and the demo code, see here:


It's a bit harder to spot on the YouTube video itself, but one can still spot the stutter.
At 0:50 you get the demo application.

Are you guys running it with static or dynamic libs?

How would that have an effect?

And my PC is high-end.

This isn't a justification not to perform some tests...

[waxx]

Oh well, maybe I tried to implement fixed timestep in a wrong and thus I implemented dt only, there might be a difference now.

https://dl.dropbox.com/u/9649932/Release.rar

Can you test it out on your end?