View size vs. Window size and pixel clipping.

[_Fiction_]

My game has a view that is 1920 x 1080. I want to be able to display the game on smaller monitors without any visual issues, and judging from what I see in other games this shouldn't be a problem. With a 1920 x 1080 window, everything works perfectly and I have no drawing mistakes. However, when I try to switch the size of the window to something smaller (in this case 1600 x 900), I get weird lines between the tiles, and it seems like the pixels are clipping irregularly or something.  You can tell in the top image that some of the pixels (easiest to see between the tiles) are a bit off. There are no problems in the bottom image. Sorry for the distracting placeholder art. In case anyone is wondering I'm rounding my view's center to the nearest pixel.

[eXpl0it3r]

Are you making sure that positions etc. are integers and not floating numbers?
How do you scale things?

[_Fiction_]

yeah, everything is on an integer pixel value. I'm not sure what you mean about scaling things. I keep a view sized at 1920 x 1080 and restart the program with window size anything less than 1920 x 1080. There isn't anything special about this resolution. Zooming out (aka making a larger view window) will cause the effect when im doing the normal 1920 x 1080 window, so it seems to be whenever the view is larger than the window size.

[Ixrec]

In that case, could you show us the code that sets the viewport and the view?  I think that's essentially what exploiter was asking for.

[_Fiction_]

i use

view.setSize( 1920, 1080 );

window = new sf::RenderWindow( sf::VideoMode( 1600, 900), "", sf::Style::Default, sf::ContextSettings( 0, 0, 0, 0, 0 ));

viewPos.x = floor( viewPos.x + .5f );
viewPos.y = floor( viewPos.y + .5f );
view.setCenter( viewPos );

[Daffern]

You have to set the view size to whatever the window size is when the window size changes. Something like this in the event loop:

while (window->pollEvent(event))
{
   }
   if (event.type == sf::Event::Resized)
      view.setSize(event.size.width,event.size.height);      
   }
}

You also probably have to play around with it to get the right results. Maybe scale the view so the whole screen fits to the window(with the same dimensions on x and y axis)

[_Fiction_]

I might be misunderstanding you, but I'm trying to keep the same amount of my game visible, otherwise people with smaller screens would basically be playing a different game.

[Ixrec]

It sounds like you aren't aware of the difference between the view and the viewport it contains.  Try rereading the tutorial on views.

[_Fiction_]

Could you explain a little more what I'm misunderstanding? From what I can tell the viewport is just the proportion of the window that you want to be filled, and the view itself is the resolution.

[Ixrec]

Yeah, pretty much.  I guess I have no idea what the real problem is at this point.

For me using this one view for the entire program
  View my_view( FloatRect(0, 0, width, height) );
  my_view.setViewport(FloatRect(0,0,1,1));
has always handled window resizing perfectly fine and I've never noticed any pixel clipping beyond what's obviously inevitable when downscaling.  I assume this is basically the same as what you're doing but I'm out of ideas.

[_Fiction_]

bump? I'm not sure what to do if the forum can't help me :|

[zsbzsb]

Ok, I will try my best to explain this  This will start to get into the world of managing screen resolutions

This is a fairly common problem and as eXpl0it3r said above the most general fix is to make sure that your view position is in whole numbers only(no floats). The reason for is not because of how SFML works, but because of how OpenGL rasterization works. With views that have positions as floats you end up with texture pixels that are supposed to be split across multiple screen pixels so OpenGL does its best to make it line up (which in this case causes lines to appear and this is where anti-aliasing can start to play in).

However in your case you have something else going on (besides float positions on your view). When you make a smaller window and then set a larger view than the window's actual size you break that 1:1 texture to screen pixel mapping and once again OpenGL has to compensate with rasterization.

There is a few things you could try to fix this, first thing that I would recommend you consider trying is to have a list of valid window sizes and then match the view's size to exactly match the window size. This way it should prevent OpenGL rasterization from kicking in. However with this method it has a one big draw back and that would be that some users of your game would be able to see more or less of the playing field depending the resolution. That is why you should have a list of valid sizes that are a not going to affect the game too much.

Another solution would be to instead of letting OpenGL make things match your view, you could instead draw everything to an off-screen buffer(sf::RenderTexture) and then scale that to match your view. A draw back of this solution is that the off-screen buffer would be limited by the GPU of your users(maximum texture size) and on older GPUs this can be as low as 512x512.

A third option would be to create a hybrid solution of the two previous solutions. Have you ever watched HD tv where they were broadcasting non HD formats? Or you may have watched something that had a different aspect ratio than your tv was? Generally in order to preserve the aspect ratio you ended up watching that show with black borders around the actual show.

The way this works is you can provide as many different window resolutions to your user as you want, but your game will maintain the same aspect resolution. You can achieve this drawing everything to an off-screen buffer and then scaling it to fit your window while maintaining the aspect. Even if that means centering it on one axis and leaving black bars on the sides of your window.

In my opinion you should go with the third option and then provide an option to the user to maintain the aspect ratio or scale your off-screen buffer to fill the entire screen (causing some distortion).

I hope this helps you