Resolutions: How can I fit all sizes?

Now I know this is not an easy question, but after how many other posts I have seen on this with no definite answer I will ask it again. How does someone make an application / game intended for multiple resolutions? I figured the best way was to make all the graphics in a high-resolution format ex. 1920x1080 and then scale down. The problems I see with this are the loss of image data is not always consistent; it varies which pixels are cut off. The other problem is, with most graphics library’s the coordinate system is base off resolution/pixel placement right? Therefore, 200x200 on a low-res screen is in a completely different place than on a high res screen.
I have also considered just rendering more of the map for something like a side-scroller, but that would give a player with a higher res screen an advantage. Another solution I have read was use vector graphics, wouldn't this make collision essentially exponentially harder? To solve the coordinate system I would figure you use a resolution 1920x1080 and multiply it by a ratio to scale it down to smaller resolutions. Like this;
 
DoThings(1980*ResoltuionXratio,1080*ResoltuionYratio)
Thank you all for your help
Another solution I have read was use vector graphics, wouldn't this make collision essentially exponentially harder?


Your graphics engine should have absolutely nothing to do with your collision detection. So no... your collision detection should be the same regardless of sprite graphics, vector graphics, or no graphics.


That said there are a number of ways to approach this problem:

1) Vector graphics -- make a 2.5D game instead of a 2D game.

2) Pick an aspect ratio, then scale up/down the image to match that ratio. For example say your "natural" output image is 640x480 and the user is using a 1920x1080 res... you could display your image as 1440 x 1080 and have "black bars" on the sides.

3) Combine technique #2 with a "mipmapping" technique. Basically where you have different images for "low res" displays and "high res" displays. For example, you could have one copy of the player graphics where each frame is 64x64, and then scale that image down manually and have a copy of it which is 32x32. Then in-game, use whichever size requires the least stretching.

4) Use technique #2, but only allow integer scaling to prevent 'blurring' and maintain a 'pixel-sharp' image. So instead of outputting 1440x1080 as mentioned in #2 (2.25x ratio) you would output 1280x960 (2x ratio). Then have "black bars" on all 4 sides.



There are other approaches as well, but these are just the ones I came up with. Each have their pros and cons, so it's up to you to decide which one you prefer.
Thanks for the extensive answer, I think #3 suits my needs the best, make some standard resolutions then scale up or down based off the stretching required. I think though I will make graphics in multiple display ratios also to prevent black bars on the side.

One Last Question... If I do use vectors, what do you mean by 2.5D? and does smfl support vector graphics?
what do you mean by 2.5D?


2.5D is a term commonly used to describe a game whose gameplay is restricted to a 2D plane, but the graphics are 3 dimensional.

A game I've been playing recently that falls into this category is Shadow Complex (great game, btw). Footage of gameplay is here:

http://www.youtube.com/watch?v=bXm4MolI8nM&feature=relmfu


and does smfl support vector graphics?


I think SFML2 added support for 2D textured quads.... but if you're looking for 3D you'd have to use OpenGL directly.
Vector graphics refers to the method of storing graphical information as a set of instructions to draw the image, instead of storing the image itself as an array of color samples (raster graphics).
An example of a vector graphics file format is SVG.

I don't know of any generic game or graphics library that supports vector graphics. The last time I went down this road, it was a nightmare. There are essentially no portable SVG rendering libraries that can't be described as "humongous".
whoops, yeah. For some reason I was thinking of something else when he said vector graphics. Har.
Ok thanks, I know what vector graphics are I just didn't know how practical they would be in C++, and as for the 2.5D I just didn't know the term for it, but thanks a lot!
Topic archived. No new replies allowed.