Some sort of flickering

[etixpp]

[...] so i am pretty sure, that this part should be fine.
[...] so it´s pretty impossible, that the map or the player or the view have a non integer value.
[...] so i think it´s pretty sure not about this :/

It would really be helpful to quit speculating and find the issue in a less time-wasting way. Obviously there is a problem somewhere, but with the information you gave us so far, it's not possible to determine it exactly.

There are of course distortions if the view is zoomed at a non-integral ratio, but I'm not sure if it's only that.

Provide a complete and minimal code example, so we actually see the problem.

Sorry, i said it the wrong way. I am sure that this part cannot cause the error.
My formulation just was caused by the knowledge i am not allways right ^^

The problem about a minimal code example would be, that the minimal version would still contain at least 3 classes and arround 2-300 main function lines, so it probably wouldn´t be so minimal any more, there is no way to just show the problem in a few lines, because normal shapes do not have the problem, so i have to pull the images, make a move and a view which get´s centered, zoom in, zoom out and so on, that´s kinda neccesary to see the problem. So if you have no problem to take a look on such a "bunch" of code i can make one tommorow.

[Nexus]

I fully understand that it's not easy to minimize the code, but at the moment I can only speculate. And if this were a problem in SFML rather than your code, it would be good to have a small representative example code.

You could try to recreate a small application from scratch. Ideal would be a texture drawn by a sprite at the problematic zoom level and the corresponding scroll rate. This should be possible to write in a single main() function without further classes or other unrelated code. It should not take very long to build this.

If you fail to reproduce the problem this way, minimize your current program step by step (and therefore be sure that the error is still reproducable). Drastically remove everything unrelated, until only a main() function is left. Please get also rid of the classes, they only obfuscate things.

In any case, make sure you follow the advice in the link I gave earlier -- make sure the code is complete (and in a single file), so that we can directly test it ourselves. If the problem happens with a certain texture, you could also upload that.

[etixpp]

ye i will go for it tomorrow, have to do some other things today aswell :/
I will post it asap^^

[etixpp]

easier then i thought.


You may take this 2 dudes as bg and main texture.
It´s possible to see it on others aswell if you look very closely but that´s the best way to notice it.
:
bg:http://riedbook.de/images/rpgbg_x2_y1.png
main:http://riedbook.de/images/rpggraphics_x2_y1.png

int main()
{
        sf::Texture bgtex;
        bgtex.loadFromFile("bg.png");
        sf::Texture maintex;
        maintex.loadFromFile("main.png");
        sf::Sprite bgsprite(bgtex);
        sf::Sprite mainsprite(maintex);
        sf::View MainView;
        MainView = sf::View(sf::FloatRect(0, 0, 1400, 1400));
        MainView.zoom(1);
        MainView.setCenter(0,0);
// set the shape color to green
       
         sf::RenderWindow  window(sf::VideoMode(800, 600), "exa");
         window.setView(MainView);
         window.setFramerateLimit(60);
         sf::Clock cooldown;
    while (window.isOpen())
    {

        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
                if(cooldown.getElapsedTime().asSeconds() > 0.001)
                {
                        if(sf::Keyboard::isKeyPressed(sf::Keyboard::W))
                        {
                                MainView.move(0,-4);
                                cooldown.restart();
                        }
                        if(sf::Keyboard::isKeyPressed(sf::Keyboard::A))
                        {
                                MainView.move(-4,0);
                                cooldown.restart();
                        }
                        if(sf::Keyboard::isKeyPressed(sf::Keyboard::S))
                        {
                                MainView.move(0,4);
                                cooldown.restart();
                        }
                        if(sf::Keyboard::isKeyPressed(sf::Keyboard::D))
                        {
                                MainView.move(4,0);
                                cooldown.restart();
                        }
                }
                window.setView(MainView);
                window.clear();
                window.draw(bgsprite);
                window.draw(mainsprite);
                window.display();
    }

    return 0;
}

My eyes already hurt cause of this shit >.>
Come on Laurent give me some EveryBugWillBeFixed() function >_>

[etixpp]

Sry for tripple post, i got the problem.
The thing is, this trouble occurs when i but View Resulotion on 1:1 or something and Window Resolution on 16:9.

So zooming in and out allways destroy it ... x.X

[Nexus]

Thank you for reducing the code. I see the problem, both the stripes and the flickering when moving. It seems to be an actual artifact of the zooming, I wouldn't have expected it to be so extreme.

As mentioned previously, you can't avoid distortions when zooming at non-integral ratios. When the number of pixels in the texture and on the screen don't match, pixels have to be either omitted or duplicated. Since these are not always the same pixels, it looks like the texture is changing during scrolling, but in fact only the texture mapping is different.

Now, what can you do? The best results can be achieved by pre-rendering the textures to fit the given scale. Either do it in an external image editor, or use sf::RenderTexture.

See also these threads:
http://en.sfml-dev.org/forums/index.php?topic=12326
http://en.sfml-dev.org/forums/index.php?topic=12888

[etixpp]

I already thought about this method.
Now the funny part:
I get the problem managed if i zoom in and only with 2 and 0,5 and use only 16:9 view resolutions.
But i absolutly can´t get my minimap managed for higher resolution´s, no matter what i do and i use sf::RenderTexture there

->My RenderTexture Function

oid HUD::DrawOnRenderTexture(int pLevel, sf::Sprite pBg, sf::Sprite pMain, sf::Sprite pColli, sf::Sprite pPlayer)
{
                        RenderTexture.clear(sf::Color(33,100,44,255));
                        sf::View testview(sf::FloatRect(0, 0,800,800));
                //      testview.setViewport((sf::FloatRect(0.75, 0.1, 0.2, 0.2)));
                        testview.zoom(1);
                        testview.setCenter(pPlayer.getPosition().x+16,pPlayer.getPosition().y+16);
                        RenderTexture.setView(testview);
                        RenderTexture.draw(pBg);
                        if(pLevel == 1)
                        {
                        RenderTexture.draw(pMain);
                        RenderTexture.draw(pPlayer);

                        }
                        else
                        {
                        RenderTexture.draw(pPlayer);
                        RenderTexture.draw(pMain);
                        }
                        //RenderTexture.draw(circle);
                        //RenderTexture.draw(pColli);
                        RenderTexture.display();
                       
                               
}

The creating of the RenderTexture is done in the Constructor of the map class
->RenderTexture.create(800,800);

And after all it gets circleshape.settexture(rendertexturestuff); 'd.

do you see a mistake on the flow? Otherwise a create one more example for this tomorrow

[Nexus]

Views with zoom ratios such as 2 or 0.5 can work when the pixels from the screen are always mapped to the same texels in the texture. In other ratios, you don't have that. Read the second link I gave in my last post, zsbzsb explained the problem in a very detailed way.

Render textures are useless if you just draw everything to them as you do with the window. You have to draw the single objects (each one) to a render texture, so that you essentially get new, scaled textures which you can then use further.

[etixpp]

So just that i understood it the right way,
instead of drawing every sprite which has the textures of the image, i create for every object i want to draw (eg background and main -> 2 rendertextures) a rendertexture, create 2 new sprites, set the rendertextures as textures of the sprites and draw them to the window?

[Nexus]

Yes. The render textures need to exist only temporarily, as you can copy their contents to a texture using getTexture(). So you can also reuse a single render texture. If you don't need the original textures and sprites anymore, you can destroy them, too.

Thus, for every object you want to draw nicely with different scale, you perform the following steps:

1. Load original texture from file
2. Create a sprite referring to that texture
3. Draw sprite to a render texture, using the new view
4. Create a new texture with the render texture's contents (or directly overwrite the existing texture)
5. Create a sprite referring to the new texture
6. Draw the new sprite to the render window, using the default view

This processing may take some time. If you know the zoom factor in advance, you can save the modified textures to files, in order to load them later directly.

[wintertime]

The simplest thing would be to avoid the nearest filtering that produces ugly edges and flickering on resizing, move or rotation.
Just always call setSmooth(true) when creating a texture. Imho that should be the default setting for most people. They possibly just make their game run and dont wanna "risk" breakage if they change some extraneous setting, but then get the lower quality output.
Only people intentionally wanting a blocky retro-look with risk of flickering and a 4 times or more enlargement of tiny pixel art would want to turn it off. Or maybe, if there exist perfectionist people who never ever resize or rotate or move at non-integer coordinate or use texture coordinates not constituting a 1:1 pixel:texel mapping and want to avoid the slightest bit of blur, they would also turn it off.

[Nexus]

Texture smoothing was enabled by default in older SFML versions. It was absolutely not intuitive and resulted in dozens of people being confused about why their sprites would look different from the image file. As a consequence, the default behavior was set to false. See here for the original discussion.

By the way, as already mentioned, texture smoothing is of limited help for the problem here.

Generally, the OpenGL rasterization rules are responsible for a lot of confusion and implementation trouble. There have been numerous discussions about them, and Laurent has changed SFML several times in order to cope with one issue, only to bring up the next one. Unfortunately there are still some pitfalls, but I don't think it's easy to find general solutions (and not only application-specific workarounds) to them, if it's even possible at all. That said, I believe the current implementation is a good trade-off and yields good results in common cases.