Android Question Problems with screen density and resolution with accelerated surfaces

andymc

Well-Known Member
Licensed User
Longtime User
I'm trying to write a simple game (flappy bird clone as a learning exercise) but am having issues with different screen sizes and densities. My code works fine on a Galaxy S2 which is 480x800 density 1.5 but other screens give me problems. I think it's when the density changes. 1.5 seems fine but anything else sends everything crazy.

I've attached the project if someone can take a look and suggest the best solution. I set a scaleX and scaleY value based on an initial screen size of 400x600 but then have issues with screen density after that.
 

Attachments

  • CloneyBird.zip
    20.9 KB · Views: 305

andymc

Well-Known Member
Licensed User
Longtime User
Oh, okay. I just thought it would as it's a more developed graphics engine. Isn't there anything that lets me just draw to a virtual canvas type thing at a set resolution that just scaled to what ever screen size and density it runs on? So I don't have to keep scaling images and coordinates all the time? Screen percentages are okay but don't work well with converting games from PC which is all pixel based in 2D to having to deal with scaling.
 
Upvote 0

Informatix

Expert
Licensed User
Longtime User
Oh, okay. I just thought it would as it's a more developed graphics engine. Isn't there anything that lets me just draw to a virtual canvas type thing at a set resolution that just scaled to what ever screen size and density it runs on? So I don't have to keep scaling images and coordinates all the time? Screen percentages are okay but don't work well with converting games from PC which is all pixel based in 2D to having to deal with scaling.
It's a bit more complicated. Due to the different aspect ratios, defining a viewport size of 640x480, for example, will not be ideal on some screens; you will have black bars on the sides if you want to avoid distortions. It's convenient for you, but not very attractive for the user and if you look at the current top games, you will see that they do not use this method (the screen is entirely filled whatever the resolution, density or aspect ratio of your device is). If your background image, for example, has a size of 1280x800 (ratio 1.6), you have to select one of the following options to display it on a 1024x768 screen (ratio 1.333):
- you don't reduce its size and you set its origin to (1024-1280)/2=-128 , (768-800)/2=-16.
- you adapt it to the screen, thus the new height is 768 and the new width is 1228 (you will lose 102 pixels on the left and right sides, so your image should not include important drawings in these areas).
- you use different images for different aspect ratios, for a more artistic panning.
- you use a nine-patch drawable so your image can be nicely stretched.

This problem is identical on a PC. Different resolutions different aspect ratios... I don't think that using only the pixel unit is a good think whatever platform you use. You have always to scale your work to fit the screen. With libGDX, you can use your own unit (tiles, meters, etc.) but, in the end, this unit has to be scaled properly.
 
Upvote 0

andymc

Well-Known Member
Licensed User
Longtime User
Okay, I think I'm getting the hang of it. Using DIPs isn't going to work really for games I think. But using percentages should work okay. I've attached a very simple example that seems to work for densities 0.75, 1 and 1.5. I'll test higher densities later. The only issue I have is my ground tiles don't tile properly on a lower screen resolution device, they leave the occasional vertical line. I think I could use some overlapping in the graphics to make up for this however.
 

Attachments

  • scalingtest.zip
    15.4 KB · Views: 324
Upvote 0

andymc

Well-Known Member
Licensed User
Longtime User
Okay, I've found the problem. The scaling changes both on the screen density being different and also whether hardware acceleration is available. So I'm just going to support hardware accelerated devices to keep it simple. this has been a major headache for me as I test my program on an emulator with a 480x800 screen at 1.5 screen density, then load it on my phone which has the same screen setup and it's different!!!! Turns out the emulator didn't have GPU host support turned on, turning this on makes it behave the same as my phone. I am not producing different graphics sets for each resolution of screen as scaling means I don't need to do this, I just need to figure out how to use scaling properly. I don't see any good examples that show this in the way I'm trying to do it.
 
Upvote 0

Informatix

Expert
Licensed User
Longtime User
The scaling changes ... whether hardware acceleration is available.

That shouldn't be the case and I never noticed it. Enabling or disabling the acceleration on my different devices does not produce any change (except for speed).

I just need to figure out how to use scaling properly. I don't see any good examples that show this in the way I'm trying to do it.

Here are three suggestions:
1) Don't use LoadBitmap as it alters the density of the image when it loads it. Instead, use LoadScaledBitmap of the Accelerated Surface library and remove AC.ScaleCanvas.
2) Split your background in two images. I can't see the usefulness of having a composite image (you have to crop and scale the two needed bitmaps, while you could load and scale directly the two images with LoadScaledBitmap).
3) If you want to be pixel precise, don't consider that 80%y + 20%y = 100%y. That's not true because of the roundings done. When you size something to 80%y, the remaining part has to be sized 100%y - 80%y, which gives a precise result. I don't think it's really important in your case but it's something to keep in mind.
 
Upvote 0

andymc

Well-Known Member
Licensed User
Longtime User
Thank you so much Informatix! That solved it! I was getting confused due to using both loadbitmap and loadscaledbitmap. Everythign seems to work great now. I've added some simple collision detection and put the game into the showcase. I won't be entering it on the Playstore as it's a clone. I'll probably make a different game bnased on the same code though and release that instead.

Thanks again.
 
Upvote 0
Top