• Create Account

## Resolution independent positioning

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

12 replies to this topic

### #1futlib  Members

Posted 14 February 2011 - 01:45 AM

Hi,

I'm working on an Android game (I don't think the issue is Android-only though) and I want to support all available resolutions and screen sizes. I studied the <a href="http://developer.android.com/guide/practices/screens_support.html">dev guide</a> and saved my background images in multiple resolutions:

- 240x432 (ldpi)
- 320x480 (mdpi)
- 480x854 (hdpi)

These resolutions have different aspect ratios. Furthermore, at each density level, there are more resolutions, also with different aspect ratios.

I solved that problem by simply centering my backgrounds. As long as I make sure that the relevant areas are visible on each device, it works fine.

However, now I want to position elements on specific spots of the image, which I am unable to achieve with my current approach. I could hard code positions for each resolution, but there has to be a better solution. Density independent pixels don't do the trick because of the different aspect ratios.

How do/would you approach this?

### #2GregMichael  Members

Posted 14 February 2011 - 02:49 AM

You could try homogenous coordinates, I started with these on iPad and thought it would make life easier going down to iPhone 4 / iPhone / iPod etc.

In the end I used a half and half approach of homogenous coordinates and actual pixel size/positions.

### #3Ashaman73  Members

Posted 14 February 2011 - 05:47 AM

One way to do it to use border relative positioning. I place my gui by using the following convention:

x coord:
=0 => center at parent container
<0 => place right border of element abs(x) pixel away from right border of parent container
>0 => place left border of element abs(x) pixel away from left border of parent container

y coord: like x coord

My gui is represented by a tree of containers, where the root is the screen and the leafs are the widgets like buttons etc.

Ashaman

### #4futlib  Members

Posted 14 February 2011 - 07:01 AM

Thanks for your replies, but I'm not really sure I understand either of your approaches, sounds quite challenging

A colleague of mine just came up with an, in my opinion, surprisingly simple solution: Since I center the background, he said I should just draw my elements relative to the center of the screen. Like in a typical OpenGL coordinate system, as opposed to those normally used in 2D graphics. I cannot find any problem with this approach, is that common for this kind of thing? Or would you perhaps argue that the whole centering-the-background-thing isn't really a good idea in the first place?

### #5haegarr  Members

Posted 14 February 2011 - 07:59 AM

It depends on how your game works. I mean that changing the resolution should not make the game easier / heavier, or else balancing would become nearly impossible. Especially things like comparing high-scores and game centers will be meaningless.

Different aspect ratios may be handled by fitting the desired view into the available screen dimensions. If the aspect ratio doesn't match, then filling the gap (or perhaps gaps if two sided) with a background not counting to the gameplay. Positioning should be done resolution independent anyway. Thinking of a camera that looks into the scene, where the camera has a view size in some virtual world co-ordinates. Then this view is sampled accordingly to the given resolution, making up the pixels the player sees. Moving objects then means to move them in units of said virtual world, not in units of pixels. You can snap to real pixel positions just for the rendering.

And supporting low and high resolution images is also possible; just hide this in the resource management. Then only rendering really needs to know the resolution.

A "typical OpenGL co-ordinate system" has its origin in the center of the screen, that's true. However, it also has an extended view that is decoupled from pixel sampling. The projection matrix will map the virtual world sized view onto the normalized view volume. So this is an example that matches what I've written above.

### #6futlib  Members

Posted 14 February 2011 - 10:40 AM

Thanks haegarr, calculating the positions sounds like the most natural approach, guess I'll do that.

By now, I'm really confused by the whole issue of resolution and aspect ratio independence. I just thought that I could eliminate the problems raised by different ratios between resolutions by just using the same size and then scaling down. For this, I calculated a "maximum screen area" and a "minimum screen area".

The maximum screen area will be the maximum of what can be seen on any device, and hence the size of background images. I calculated this to be 480x864.

Then I've pondered a bit over the numbers and came to the conclusion that the minimum screen area will be 480x640 respectively, to support all resolutions. If I make sure that all relevant parts of the background are shown within this area of the center of the background and that all elements are positioned within it, my game should work on all available resolutions.

These numbers will be scaled down for mdpi and ldpi.

Does this sound like a reasonable approach to you?

Furthermore, are the following really all possible screen sizes of Android devices?
• QVGA (240x320)
• WQVGA400 (240x400)
• WQVGA432 (240x432)
• HVGA (320x480)
• WVGA800 (480x800)
• WVGA854 (480x854)

### #7way2lazy2care  Members

Posted 14 February 2011 - 01:43 PM

perhaps you should try
smartly using matrices
transforming nicely

### #8GregMichael  Members

Posted 14 February 2011 - 04:13 PM

perhaps you should try
smartly using matrices
transforming nicely

When you've got a game to ship and the client breathing down your neck - BODGE IT AND SCARPER.

Do it correctly on the next project

### #9B O N E S  Members

Posted 14 February 2011 - 05:58 PM

Well if I was doing it then I'd create a simple scale coordinate system. Get the resolution size and go from there(ex. Divide to find the middle). Then you can set x and y scale to 0.5 and no matter the size, it will always be in the center.

### #10frob  Moderators

Posted 14 February 2011 - 07:15 PM

Another general purpose "surprisingly easy" approach is to just add black bars as needed, and render at your own preferred size.

This works nicely even on windowed environments, not just full screen. If the display window is too wide, draw it as maximum height and put black bars on the sides. If it is too tall, draw at maximum width with bars above and below. Keep your game in a floating point 0.0 to 1.0 size so you'll still be able to access each individual pixel for any size screen currently imaginable.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #11futlib  Members

Posted 15 February 2011 - 09:00 AM

perhaps you should try
smartly using matrices
transforming nicely

You lost me there, would you mind elaborating on this?

Another general purpose "surprisingly easy" approach is to just add black bars as needed, and render at your own preferred size.

This works nicely even on windowed environments, not just full screen. If the display window is too wide, draw it as maximum height and put black bars on the sides. If it is too tall, draw at maximum width with bars above and below. Keep your game in a floating point 0.0 to 1.0 size so you'll still be able to access each individual pixel for any size screen currently imaginable.

That sounds reasonable, but I'm a bit worried that if we use the "minimal screen area" (that one which will be visible on all resolutions) and add black bars on all larger screens, we will effectively see black bars on almost every device. Guess it's okay though, the user will probably not notice and it doesn't really matter whether I use black bars or more of the background image, the space can't be used for gameplay anyway. Technically, the solutions are very similar, I just have to center the background vertically.

The 0.0-1.0 based positioning idea sounds really good to me, guess I'll do that. Less confusing than to work with a reference solution. But I will also see if Android's density independent pixels do the trick for me, because I won't be able to use the former in layouts.

### #12way2lazy2care  Members

Posted 15 February 2011 - 09:24 AM

perhaps you should try
smartly using matrices
transforming nicely

You lost me there, would you mind elaborating on this?

probably because I answered in haiku. You should be able to draw to a standard size, then use a transformation matrix to alter it as needed to fit all resolutions.

android should handle a lot of the resolution independence for you though.

http://developer.android.com/guide/practices/screens_support.html

### #13futlib  Members

Posted 16 February 2011 - 01:18 AM

perhaps you should try
smartly using matrices
transforming nicely

You lost me there, would you mind elaborating on this?

probably because I answered in haiku. You should be able to draw to a standard size, then use a transformation matrix to alter it as needed to fit all resolutions.

android should handle a lot of the resolution independence for you though.

http://developer.and...ns_support.html

Ah, I see. Well, although it's the title of this post, "resolution independence" is not really the problematic part of what I'm trying to do. Android's density independent pixels are everything I need for that. My problems lie with aspect ratio independence, but I think the two approaches that emerged in this thread are fine:
• Just center the visible area and have small black areas above and below.
• Make a background image that's large enough to fill every devices screen and center it for smaller devices, making sure that everything of importance can be seen on all devices.
I think I'll actually do both of this. The second approach for my current project and the first approach for the next one.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.