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

So I have chosed a working size of say 1928x1080 and all rendering including the UI are based on that size, now my issue is if the screen aspect ratio or the size is different, it results to my scene looking like stretched.

Is this the right approach in handling multiple screen size or are there any other approach?

also, say if I have a terrain with 1000x1000 pixel and the screen size is small, does the camera render only a portion of the terrain and when the screen size increases it can see a lot of the area in the terrain?

Perhaps im asking if when the screensize changes, does the range of the visible scene ranges also or should there wont be different whether small or big screen size and player should see the same items on screens althoug distorted? Which is the better approach?

Any leads, information, links, books or resources that I can read or check is a great help

thank you in advance!

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.

When I was in mobile development for some smaller to major Apps, the screen size was always coupled with a certain set of Assets. For the engine itself, it only matters when the screen isn't a power of 2, especially on iOS devices. Their chips like PoT best, for example when you have texture compression PVRTC enabled. Android gives a sh*t on that most of the time.

For Assets, this is way different because as you already mentioned, UIs and anything may be made for a certain resolution. Some Apps then provide a scroll or scale down so that it isn't possible to read anything anymore. I've seen this behavior already in some major company Apps like Konami. This is why I always had different Asset packs for certain screen size. Those Assets had a name appending the minimum resolution and I then picked those Assets that were greater or equal my current (at runtime detected) resolution but not less.

So as an example when an Asset was made for 1024x768 then I picked that Asset if the screen was greater or equal 1024x768 but smaller as for example the next higher resolution Asset named 1980x1024. You have to be prepared for everything in mobile development, especially for such exotic devices as Samsung Galaxy Fold series