cebugdev2 said:
I have my own openGL ES engine that adapts to multiple mobile screen sizes by rendering the scene to a backbuffer and rendering the texture to the screensize just like how it is described here:https://www.intel.com/content/www/us/en/developer/articles/technical/dynamic-resolution-rendering-on-opengl-es-2.html
Didn't check the link, but usually you'd do this for performance reasons. Rendering at lower resolution to hit the target framerate.
Or you'd do it to have full multi sampling for higher quality but worse performance.
You seemingly do it to make just one version of a game, rendering at constant resolution, and then scaling up or down to support various screen sizes.
But that's not a good idea, as you waste GPU performance on devices with small screens. Or you waste screen resolution on big screens, which usually also come with more powerful GPU.
The better way would be to author content at various resolutions, or do the scaling while rendering to the native screen resolution, or do the scaling on loading the content just once.
When i made a game for cell phones there were no GPUs (and no scaling) yet, so authoring for multiple resolutions was the only option. Also screen sizes of devices varied wildly.
So i made the tileset and sprites at those resolutions: 12, 18, 24 pixels.
I also had a fixed virtual ‘safe frame’ resolution like 13 x 19 tiles. I made sure on every device you can see at least this area, and i've chosen the tileset which was within this constraint but as large as possible.
The levels of my game had different sizes, e.g. 200 x 100 with scrolling. Result was that on some devices you could see more of the level, on others less. But it was guaranteed you can see at least 13 x 19 tiles on any device, and i designed the levels with this size in mind.
This practice worked well for the puzzle game, where it was important the player can see various events like opening a distant door with a switch.
It's probably less relevant today, because resolutions of smart phones are all high and not that different from each other. But in some cases it might be still needed to author multiple content resolutions maybe.
You can use a similar practice to avoid stretching. Define a safe frame, design for that, allow some undefined amount of content to be visible in the overscan area beyond that, which is then either on the horizontal or vertical edges.
Should work fairly well for any genre.
Another option i have used for a smart phone game was a slightly tilted 3D perspective view. The game was designed like a top down game, but by choosing the proper tilting angle the whole level did fit on screens with any portrait ratio.
Works only if your content is 3D ofc., which also usually avoids a need to author multiple versions.
To me, this variable screen size issue caused some extra work, tweaking and testing, but it never was a serious problem or game breaker.
There is no single solution which is best for any game, though.
GUI elements can be scaled and placed according to screen size. No big problem either. You just don't know where they will end up exactly.
It also helps to have multiple settings of typical screen sizes, which you can switch easily while developing on PC.
