Multiple screen resolutions / aspect ratios (games)

EDIT: Thanks for your answers and comments. Thinking about it, I would rephrase the essence of the question: "How to determine and limit the minimum resolution / ratio that my game can play." Since an IMO or a game becomes unplayable on the smallest screen / ratio (lack of detail) or supporting even the smallest screen / ratio, significantly worsens the experience for everyone else. Furthermore, we don’t even know what the smallest resolution is or it can limit it in any way, except to disable ldpi ... which still does not tell us about the smallest mdpi. In the end, I don’t think about how to create a good result, but how to create an ideal result;). Guess it is not possible (yet?).

Note: These are purely phones, not tablets. Also this question is not suitable for applications, as for games that do not use the Android layout system.

I have always found definitions of which solutions to expect somewhat vaguely. I know the list in the docs.

Now my first question is whether this list is complete or, in other words, the manufacturer is allowed to use other coefficients or proportions. My current approach is to look at this list in terms of aspect ratio, which looks something like this (not sure if it is accurate, but you get the idea):

  • ldpi: smallest aspect ratio 4: 3
  • mdpi: smallest aspect ratio 3: 2
  • hdpi: highest aspect ratio 16: 9

4: 33: 216: 9

So, if I want to cover a range of devices, I will find out what my smallest and my largest proportions are, as well as the layout design for the smallest, and at the same time it automatically grows to the largest. For example, if I want to support all densities, I design the screens at 4: 3 and increase them to 16: 9. In the event that I remove ldpi support, I would develop for 3: 2. Of course, this assumes that there will never be mdpi device with a 4: 3 aspect ratio, which brings us back to my first question.

My preferred solution would be to point out to the Android Market what proportions my application can handle, but for now this seems impossible.

Does anyone have a better approach? (Keep in mind that this is only for games on phones)

+44
android screen-resolution aspect-ratio
Aug 15 2018-11-11T00:
source share
6 answers

I found a clear answer to this problem.

Minimum permissions: undefined up to 3.0. Thus, for version 3.0 and higher, it will be possible to select the minimum resolution, design a game based on it, and dynamically deploy the layout on large screens / coefficients, as mentioned by the supermer and others.

As you design your user interface for different screen sizes, you will find that each design requires minimal space. So, each generalized screen size above has a corresponding minimum resolution, which is determined by the system. These minimum sizes are in units of "dp" - the same units you should use when determining your layouts, which allows the system not to worry about changes in screen density.

  • xlarge screens at least 960dp x 720dp
  • large screens of at least 640dp x 480dp
  • regular screens at least 470dp x 320dp
  • small screens at least 426dp x 320dp

Note. . These minimum screen sizes were not well defined prior to Android 3.0 , so you may encounter some devices that are incorrectly classified between normal and large. They are also based on the physical screen resolution, so it can vary depending on the device - for example, a tablet with a resolution of 1024x720 with a system panel actually has a little less space available for the application due to the fact that it is used by the system panel.

Source

+4
Aug 24 2018-11-21T00:
source share

I cannot directly answer your question, but I would like to tell you my approach. I try not to use any numbers. Instead, I'm trying to use paddings, margins, and relative layouts so that my looks look right on any phone. It also helps me avoid creating views for different orientations.

+19
Aug 19 '11 at 16:11
source share

As mentioned earlier, my approach will also make full use of device-independent components, such as paddins, fields, and relativelayouts, in combination with the device’s stand-alone puxels.

To be honest, I hope that I'm not the only one, but I fully use DIP (device independent pixels) and relative layout and such ... reduced my activity layout files to 1 by activity, not 3 different types for HDPI , MDPI and LDPI.

if you are really concerned about the aspect ratio, you can always call up the screen properties in the pixels of the device and carry out the corresponding calculations based on these numbers. You can call this at the very beginning of the onCreate method of your first action.

Display display = getWindowManager().getDefaultDisplay(); int displayWidth = display.getWidth(); int displayHeight = display.getHeight();

this will give you the width and height values ​​of your equipment in pixels. In my opinion, the true reason why you have chosen more than three types of layouts is to provide a clear image resolution.

Using these numbers, you can do some internal logic that calculates the type of resolution images to load in some widgets. Thus, you save you from having to do 3 times the same layout ....

can be explained a bit cryptic, but the main thing to overcome various device resolutions is to work a lot with:

  • relativelayouts
  • Device Independent Pixels

You can also define DIP in the XML layout so that each component looks the same on all types of devices.

maybe a stupid example, but hey, it worked for me :-) here below I tried to get the size of the text in text form relative to one on all devices. You can call the "TypedValue" class and select one of the many public variables offered there. Since I wanted the TextView everywhere to be the same relative size, I used the following code:

 someTextView.setTextSize(TypedValue.COMPLEX_UNIT_DIP, 18); 

you must indicate how large the value is in the DIP. TypedValue can be used in many widget or activity components that require an INT value for dimension properties. Play with it and you will see that life is much simpler: -p

hope this answer helps a little

+4
Aug 21 '11 at 12:26
source share

There is no exhaustive list of proportions. Manufacturers can decide which solution they want. In addition, the aspect ratio does not match the pixel density, so using ldpi / mdpi / hdpi to determine the aspect ratio is probably not a good idea.

Your strategy for dealing with this really depends on your game. Of course, to a certain extent, you should simply scale more / less, but obviously the edges are complex, which differ from each other in different proportions. Some games (first-person shooters, side scrollers, braided top-down games, etc.) you can simply provide a different field of view without any problems if you are not interested in providing benefits to certain devices, others you might think about stretchable or tiled graphics for the background and maintain the same effective (scaled) game zone.

+3
Aug 19 '11 at 18:28
source share

You can try asking GameDev.stackexchange.com

Here is a similar problem for you: creating a game for different phones with reclamation

+2
Aug 19 '11 at 17:12
source share

You can limit which devices can see your game on the market by screen resolution: http://developer.android.com/guide/appendix/market-filters.html

I haven’t delved into it completely, but I don’t see any mention of aspect ratio, so you may have to fill in everything that you know will work.

Otherwise, you can set the minimum resolution necessary for your graphics to look good, and if you do not want to change the game for lower coefficients, you can add black borders, as it would be in console games. However, it is not recommended that the space on the mobile screen be valuable enough, so if you cut the playing field with black stripes, I would move your HUD to a black area so that you still use as much screen as possible.

Here's more info on supporting screen sizes: http://developer.android.com/guide/practices/screens_support.html

: D

0
Aug 24 2018-11-11T00:
source share



All Articles