How to handle different resolutions?

[Satus]

Hello, guys.
I am not new to programming itself, but I am a complete noob in game development or working with graphics. So recently in my free time I started working on some simple 2d game using SFML and C++11(14).
The questions I've been thinking is how game developers handle different resolutions and screen sizes that their games are run on? What if I want to develop a game for both PC and mobile? Should I have different textures for every resolution I want to support?
Sorry if my question sounds stupid, as I said I am very new to this.

[GraphicsWhale]

I am not new to programming itself, but I am a complete noob in game development or working with graphics.

You should check out gamedev.net. Likely better help for learning to program games. This forum is really mostly for SFML-related stuff.

The questions I've been thinking is how game developers handle different resolutions and screen sizes that their games are run on?

There is no magic bullet for supporting many resolutions.

Do you want the height to stay the same and only adjust for the width? Do you want the width to stay the same and only adjust for the height? A mix of both? A mix of but effect one more than the other? Or just add black bars? These are decisions you're going to have to make yourself.

How they're implemented? Math. It isn't too difficult. For example: say you have a tilemap that you want to handle multiple resolutions, just divide the width of the window by the height to get the aspect. Start off with two constants for how many tiles you want to see horizontally and vertically assuming the window is square, say 10. Then if the aspect is bigger than 1 (1 being completely square, < 1 being tall, >  1 being wide) then multiply the width (which starts off at 10) by the aspect, and if the aspect is smaller than 10, divide the height (which also starts off at 10) by the aspect.

So again, if the window is square, you see 10x10 tiles.

If the window is 800,600, the aspect is 800/600=1.33333. Since it's bigger than 1, multiplying the width (10) by the aspect makes 13.33333. So you see 13.33333 tiles wide and 10 tall. So each tile is now perfectly square to the view. If your window is 800,1200, the aspect is 800/1200=0.66666. Since it's smaller than 1, dividing the height (10) by the aspect makes 15. So you now see 10 tiles wide and 15 tall.

That's just an example, but hopefully you understand how math ties into making your stuff look good at different resolutions.

Some methods utilize math directly involving the size of the window, others involving a normalized range (0,1). Just don't draw assuming you're only going to be using one resolution and you'll be file.

What if I want to develop a game for both PC and mobile?

That's something you should worry about once you have a game to port. Once do have that, you'll probably have a lot less questions than you do now.

[Jesper Juhl]

Other options in addition to what GraphicsWhale mentioned are:
- scaling your graphics up or down to fit (possibly using a sf::View or sf::Sprite::setScale()).
- having multiple sets of assets for different resolutions.
- run in a fixed size window of minimum resolution and just not deal with it.

[Hapax]

If you choose the "black bars" / "letter-box" method, this page on the Wiki might save some of that work.

[Satus]

GraphicsWhale, thanks a lot for you answer. So if I understand you correctly, I should simply scale my sprites accordingly to the aspect ration and resolution of the screen?

[Jesper Juhl]

You can scale your sprites if the result is acceptable to you - sure; it's one way to go.
If scaling doesn't produce the visuals you want, then letterboxing or providing different assets for different resolutions is probably the way to go.
It all depends on what you want to achieve and what quality of results you require.
There is no single "just do this" option that will work for everything.. It all depends on what you want and what you are willing to accept.

[Satus]

Thanks you all for your help. I am sure I will use it later in my project.