-
Hej guys, i created a video to show you what i mean
http://www.youtube.com/watch?v=AalWbLu21fQ&feature=youtu.be
The thing is... i really got no clue what could cause this, i discommented everything except the map rendering...
Its kinda hard to create a minimap example for this... could this be caused by my graphic card / driver or something? Normally everything should be fine with this...
If you don´t see, there are something like "Stripes" i only notice them if i zoom out kinda much but this stripes are creating some darker and lighter layers and a flickering... you can notice it best at 00:37 .
Its probably kinda senseless to show code here cause there are a lot of dependencies and unneccesary stuff, so before i try to create a minimal example i just wanted to ask if somebody had this once aswell and knows a cause or solution :)
Ok, just for your Info, i checked a few more things now:
-2 Mates have the same prob with my executable, so i am pretty sure its not about the graphic card
-i discomented every drawing except the background and this layers still exists with the same phenomen, so i am pretty sure it´s not about too much drawing on a frame
-Not about Fps aswell, i tried with 30, 60 and unlimited, no reaction
-
I guess you mean the vertical stripes in the teal area starting at 0:37. Does it look exactly like that in the original application (even when not recording) and isn't this the result of video compression?
Do you adhere to the clear/draw/display cycle for every frame? And there is no texture or shader involved that may cause such a result?
Try to reproduce the problem by rendering only the teal area. Then your code should be minimal.
-
No, its not only in the video, its in the main application >.<
My clear Draw Display Area looks like this atm
->
window.clear();
MainMap.RenderActualMap(window,MainPlayer,MainRenderChunk,MainView);
/*display window gui and so on */
if (EscMenue)
{
desktopx.Update(1.F);
sfgui.Display( window);
}
// MINIMAP
UserInterface.DrawOnRenderTexture(MainPlayer.GetPlayerDirection(),MainRenderChunk.GetBgSprite(),MainRenderChunk.GetMainSprite(),MainRenderChunk.GetCollisionSprite(),MainPlayer.GetPlayerSprite());
UserInterface.update(MainPlayer.GetPlayerSprite(),window.getView(),window);
// TGUI Für statisches Menü. Atm nicht nötig gui.draw();
//RECOURCE DATAwindow.draw(loadstuff);
window.draw(LocalRectangle);
for (int i = 0; i < ZoneContainer.size(); i++)
{
window.draw(ZoneContainer.at(i));
}
window.display();
But i deleted everything except this for testing:
window.clear();
MainMap.RenderActualMap(window,MainPlayer,MainRenderChunk,MainView);
window.display();
RenderActualMap just draw´s the Background, Foreground and Player and a few physics, i deleted everything there aswell except background and player, still no reaction >.<
This vertical Things are like Layers, they go over the HUD etc. aswell if i draw it and if i zoom out enough, it can even overlay parts of the HUD
-
What happens if you draw only the teal texture? That is, get rid of all custom code such as RenderActualMap() or SFGUI. Simply use an image file that contains nothing but the teal background, load it with a sf::Texture and draw it using a sf::Sprite.
If you provide a minimal and complete example (http://en.sfml-dev.org/forums/index.php?topic=5559.msg36368#msg36368) that reproduces the problem, you help us find the problem, and we don't waste time with guessing.
-
It does no problems with Sf Image and some Color Fill, but that does not make it better ... D:
I have no clue what could cause it with the texture, the only thing i notice it, that it´s only a realy big problem if i zoom out a lot, but still even if i dont, if i look carefully i can exactly see what happens,
created one more video to show what´s about the view->
http://www.youtube.com/watch?v=FkGHda8o80U
-
Looks like screen tearing, how are you limiting your FPS?
-
screen tearing <- That´s the word i was looking for D:
But i still think its something about the view, if i zoom in very much the problem disappears >.<
window.setFramerateLimit(60); // FPS
-
window.setFramerateLimit(60); // FPS
Lets say it this way, setFramerateLimit is not perfect when it comes to preventing screen tearing. Instead you should use window.setVSyncEnabled(true) to avoid screen tearing.
On my own laptop, if I don't use VSync I always will get screen tearing with just setFramerateLimit. So what I do is that I first enable VSync and then measure the FPS over multiple frames, if it is over the acceptable limit I then use setFramerateLimit.
-
Make sure you set the view to and game objects to integer position. Also try to play around with the zooming factor, so it isn't off big time.
For screen tearing the first solution one should try is turning on VSync.
But I wonder, why is your game so much stretched in the width, like the ratio doesn't fit at all, thus can of course also lead to issues.
The fact that the cross on the minimap texture is disappearing is because the texture gets scaled and not all pixels can be mapped 1:1 thus OpenGL has to interpolate, which can remove the few pixels width line.
-
i tried setVerticalSyncEnabled but did not help at all >.<
I played a bit with the ratio aswell, should not be the problem :/
The fact that the cross on the minimap texture is disappearing is because the texture gets scaled and not all pixels can be mapped 1:1 thus OpenGL has to interpolate, which can remove the few pixels width line.
Ye that seems legit, isnt such a problem anyways, i just thought it could have something together with the strips.
I just cheked all Objects should be integer positioned
-
i tried setVerticalSyncEnabled but did not help at all >.<
I played a bit with the ratio aswell, should not be the problem :/
Be sure you are not using setFramerateLimit and setVerticalSyncEnabled at the same time. Also are you sure that the VSync is being turned on? (What is your FPS with just VSync?)
Also depending on your GPU manufacturer, it may be possible to force VSync on for all applications. If you can force VSync on try to do that and see if it makes a difference.
-
i tried setVerticalSyncEnabled but did not help at all >.<
I played a bit with the ratio aswell, should not be the problem :/
Be sure you are not using setFramerateLimit and setVerticalSyncEnabled at the same time. Also are you sure that the VSync is being turned on? (What is your FPS with just VSync?)
Also depending on your GPU manufacturer, it may be possible to force VSync on for all applications. If you can force VSync on try to do that and see if it makes a difference.
I took care of this.
58-62 fps
-
It's not screen tearing, that would only be lines that separate vertical parts of the screen, as a result of more than one frame being visible at the same time.
Concerning integer coordinates, make sure that position and origin of each drawable object, as well as center, size and zoom factor of the view are integral (just to see whether the issues disappear then).
-
The map which is the only affected object (Shapes or something do not give a shit on it) is at position and origin 0,0 and never changes, so i am pretty sure, that this part should be fine.
The view center allways gets done by something like this:
MainView.setCenter(MainPlayer.GetPlayerSprite().getPosition().x+16,MainPlayer.GetPlayerSprite().getPosition().y+16);
And the Player allways moves only 4 pixels, not more and not less, so it´s pretty impossible, that the map or the player or the view have a non integer value.
The view without defined is like this
MainView = sf::View(sf::FloatRect(0, 0, 512, 512));
MainView.zoom(1);
And makes problems without zooming in or out, if i go for 300,300 size or something like that it goes to a acceptable size (same effect as zooming in a lot).
i dissabled everything else and still problems, so i think it´s pretty sure not about this :/
Viewsize 400,400 is like a absolute charm, couldnt be better, if i put 700 700 without zooming out or something, just the size of the view, its already messed up >.<
-
[...] 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.
-
[...] 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.
-
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.
-
ye i will go for it tomorrow, have to do some other things today aswell :/
I will post it asap^^
-
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 >_>
-
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
-
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
-
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
-
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.
-
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?
-
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.
-
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.
-
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 (http://en.sfml-dev.org/forums/index.php?topic=4290) 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.