Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: How to design pixel-perfect graphics and UI layouts on Android devices?

  1. #1

    How to design pixel-perfect graphics and UI layouts on Android devices?

    Hi guys, as you might already know, WILL and I have been recoding and developing his "Subject 33" project (see below):
    http://www.pascalgamedevelopment.com/showthread.php?2970-Subject-33-Restarted


    One issue we have come across is how on earth do we deal with Android devices and their differing resolution sizes+screen DPIs when trying to design graphics and layouts - Google doesn't want people to think in pixels, but device independend pixels (DPs), and we can't seem to think in this mode yet

    We have been banging our heads around the concepts, and we are struggling to work out how we can design some control layouts for a game on different resolutions so that they don't obscure the game maps, etc. in the game.

    We have designed some layouts for 800x480, 1024x800 (I think), and one other...but we don't know how they will work on devics that don't match those resolutions

    Are there any Android developers here who might be able to help explain to us how we can do this?

    EDIT: we are using Oxygene for Java + libgdx at the moment, hence me posting here

    cheers,
    Paul

  2. #2
    hey,

    until you dont want remake every grafic you should stick for a resolution of 320x480 and then scale up for higher resolutions. its also useful to design GUI elements with some space to every border so if a device miss some space it still fits the screen

    in my Math Warrior the backgrounds grafics are slightly bigger then the screen so it fit the most resolutions

    since i got some problems too with the different devices and was asked alot how to fix, i contacted a friend of mine who use HTML5 to develope for android devices, he was telling me that he always gather the resolutions of the newest android devices and some mid-range products that have similiar resolutions and he only design to fit this devices, the rest is just bonus he said

    the ouya might be a special case where i personally would make a version just for the ouya to deliver a good quality product and be a part of the minor goldrush it might bring

    if i totally missed the point i still hope it is somehow useful

  3. #3
    I believe the general idea is nolonger to create layouts for fixed resolutions but to scale according to the actual resolution of the device, given a target resolution. (I'm not sure if Oxygene does these things for you or that you have to do that manually). It may also be necessary to include several versions of images to prevent blurry textures when they're viewed on resolutions far larger than what you initially designed them for.

  4. #4
    First of all DPI is not used for refering to Device independat pixels but Dots per inch.
    http://en.wikipedia.org/wiki/Dots_per_inch
    DPI tels you how many dots or in case of screens pixels it is needed to render 1 inch sized line.
    So insted of thinking in pixels you should start thinking in inches centimeters or such. So you say I wan't this control to have 1 cm of height and 5 cm of widht. And then you calculate how much pixels would you need for achieving such widths and heights based on devices DPI information.
    Now the problem arizes becouse you won't be able to have your textures designed for all spcific DPI's at the same time so you will have to scale them on some devics and thus unfortunately lose some quality.

    Now I belive that best aproach would be using Vector based graphics so you can resize your controlls as you need. For representing controll you should use some repetive background texture used for drawing controls surface and another controll texture which defines how this background texture is rendered (shape, shading effects, etc.).
    Background texture should never be scaled. For this you would need several versions of it to fit major DPI differences.
    Control texture always get scaled to fit the actual size of the controll.
    Now if you are woried that using such aproach all the time would lead to performance loss, you can go and use it only once (upon application loading) instead to proceduraly generate the textures which would then be used (as ordinary textures) for rendering your game objects. This can be especially suitable for mobile phones and tablets since their screen resolution never changes. You could ever go and save theese proceduraly generated textures to the mobile device so they can be used the next time your game is used (faster game startup).

  5. #5
    As far as i can see, Android still lets you think in pixels
    http://stackoverflow.com/questions/1...een-dimensions

    Thinking about it, it is a fundamental requirement if you are to do any OpenGL graphics. You just have to know width/height in pixels. Ask that from the OpenGL context or something if it comes to that... I know you may not be using exactly that API, but there should always be a way.
    Last edited by User137; 17-05-2013 at 09:27 AM.

  6. #6
    Thanks for the replies so far guys, much appreciated
    @SilverWarrior: For your information, DP does stand for Density-independent pixel (dp) with Android, but you are right in that DPI stands for Dots Per Inch.
    In Subject 33 we can't use vector graphics as all the in-game graphics are currently retro pixel style images, so we have to stick with textures at this time unless we want to do a total redesign.

    It looks like some rethinking might be in order on our parts LOL

    Feel free to toss any more tips/pointers our way


  7. #7
    Quote Originally Posted by paul_nicholls View Post
    In Subject 33 we can't use vector graphics as all the in-game graphics are currently retro pixel style images, so we have to stick with textures at this time unless we want to do a total redesign.
    I thought so. That's why I mentioned option for programaticaly generating necessary textures during first run so they could fit best for target device. Now you don't need to redo all of the ingame textures this way. Only redoing textures which are then used for UI would probably be enough as I have a feling those are causing you most of the problems.

  8. #8
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Hey all! Thanks for your advice so far.

    To give everyone an idea of our design dilemma here are the 3 layouts (larger layouts are a bit older and not as up-to-date as the small one!) I came up with for phones and tablets on Android. The per-pixel specs on them is 800x480 for small and 1280x800 for the larger.

    UI-Template-Android-800x480.jpg
    800x480 1x scale Game Map (Small Android)

    UI-Template-Android-1280x800.jpg
    1280x800 2x scale Game Map (Android Tablet)

    UI-Template-Android-1280x800-2.jpg
    1280x800 2.25x scale Game Map (Android Tablet)

    Now I know that these do not match up with what Google specifies as it's preferred dp sizes. However this is my problem. How can I make my layouts match up with what Google proposes, which to my opinion is a rather tiny scale of (dp) pixels, dots, tiny blobs of colour, whatever you want to call it. I need to display all 19x19 tiles and they are only 16x16 in pixel size so it's not like I can pretend to smoosh them into individual 8x8 or 4x4 dp space and imagine everything will be ok. The dp unit scale size they specify is just TOO SMALL to design a nice interface going with their numbers.

    From the Android developer site:

    As you design your UI for different screen sizes, you'll discover that each design requires a minimum amount of space. So, each generalized screen size above has an associated minimum resolution that's defined by the system. These minimum sizes are in "dp" units—the same units you should use when defining your layouts—which allows the system to avoid worrying about changes in screen density.


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


    Note: These minimum screen sizes were not as well defined prior to Android 3.0, so you may encounter some devices that are mis-classified between normal and large. These are also based on the physical resolution of the screen, so may vary across devices—for example a 1024x720 tablet with a system bar actually has a bit less space available to the application due to it being used by the system bar.


    I need to either limit stupidly small screens or fortify some kind of screen-space guarantee in the game code that I can fit 19 of my map tiles from top to bottom and still have a fair enough space on screen on either side to fit my virtual game controls. If I we can't hit *every* device under the sun, thats ok (people are smart enough to know what they are buying) as long as the ones our game does supports will at least look nice.

    I'm quickly becoming "not a fan" of the Android platform because of this poor choice in target screen sizes. Can some Android dev rockstar post from this and change my mind?
    Jason McMillen
    Pascal Game Development
    Co-Founder





  9. #9
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Oh and no overlapping of the d-pads on the map!

    The 2.25x scale mapping layout where I have the weapon select buttons is an exception because it's unlikely that I'll have important tiles in those spots, but that may change with my recent addition of game map features.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  10. #10
    Quote Originally Posted by WILL View Post
    Now I know that these do not match up with what Google specifies as it's preferred dp sizes. However this is my problem. How can I make my layouts match up with what Google proposes, which to my opinion is a rather tiny scale of (dp) pixels, dots, tiny blobs of colour, whatever you want to call it. I need to display all 19x19 tiles and they are only 16x16 in pixel size so it's not like I can pretend to smoosh them into individual 8x8 or 4x4 dp space and imagine everything will be ok. The dp unit scale size they specify is just TOO SMALL to design a nice interface going with their numbers.
    Why is dp unit scale size too small? Small sized screens (2 to 3 inch in size) have athleast 426dp x 320dp units. This means that each tile could be 16dp x 16dp in size. (320dp / 19 = 16,84).
    Now the number of actual pixels that each dp have depends on DPI and is calculated like this: px = (DPI / 160).


    Quote Originally Posted by WILL View Post
    I need to either limit stupidly small screens or fortify some kind of screen-space guarantee in the game code that I can fit 19 of my map tiles from top to bottom and still have a fair enough space on screen on either side to fit my virtual game controls. If I we can't hit *every* device under the sun, thats ok (people are smart enough to know what they are buying) as long as the ones our game does supports will at least look nice.
    So if you have each tile 16dp x 16dp in size tihs means that for rendering the map you would need 16dp * 19 = 304dp. This means that you still have 426dp - 304dp = 122dp combined or 61 dp of space on each side of the map for rendering your virtual controls.

    NOTE: For my calculations I used dp resolution for small sized screens as presented on Android developr site. If I understood what is written there you need to request actuall dp resolution from the OS itself since some versions of Android OS can have their own permamently visible controls which would mean that you actually have less space available.


    You see dp is actualy a new measuring unit (similar as inches, cm, etc.) which will tel you how big will your UI controll be on your device independently of devices DPI and screen size. So if you you place several devices with different DPI's and screen sizes and all of them have size for one control defined as 20dp x 30dp this controll would look the sime size on all of theese devices. Well there is suposed to be some smal deviation in actual size.
    If you look at table defining dp sizes for different sized screens you see htat larger the screen is more dp it has (bugger surface).

    The main advantage of using controls whose size is defined with dp-s is that OS actualy takes care about caclulating width and height of your controll in actual screen pixels.
    Disadvantae of this is that one dp may actually be 1,5 x 1,5 screen pixels in size which would lead to quality loss when scaling images.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •