Mobile screen size database

[erico]

Not directed related to GLBasic, but this will be good for the mobile devs out here.
I have been struggling to find appropriate screen res, I mean, the most used ones as I will probably have to hard code them into my game.

Found this site today, made me happy

http://screensiz.es/
http://typecode.com/blog/whats-the-screen-size/

Hope it helps you guys out too.

edit: typed tooo fast, bad english :p

[Ian Price]

Cheers erico - could come in very handy 

[erico]

There is also desktop and tablet sizes there, I didn´t notice the tab.

[bigsofty]

A simple thing, that you don't need until you realise you need it, thanks Erico! 

[erico]

I´m glad you guys find use for it

Now, if you let me babble a few things about my experiences with it...

1. I quite can´t use the scale-to-all routines for mobiles and pads available on our forum yet . That is a flaw I will have to check out. So currently my game scales without proportion on the more weird resolutions. So far, where I tried, it is all fine, but I will try to implement a wider screen and try to keep it scaled 1:1 on most devices. This I believe I can do, since the game already checks and is working on objects outside the screen play. I´m still not sure if it is worth the trouble couse as it is, it is fine. It would have been wiser and easier to have started development considering this issue. But the point, is that I will have to hard code a set of android resolutions and the game will be for these devices, hence this list shows percentage of use (not updated but quite spot on).

2. I never gave a fart about DPI on visual screens and always took it for print only. How wrong I was...While my game goes fine on a note II and probably cool on larger tablets... some small devices the buttons are too small to work out and the experience is bad. That may also happen with text too. If I scale things down to the smaller screens, then the buttons are the size of a potato on tables and big phones and this also deprive the experience. I find it really horrible to have on screen controls, But analyzing screen size and resolution, I could come out with a proper set of buttons that won´t offend neither. Here again, it could be wise to code the on screen controls (ye virtual joy, buttons) considering that, so suddenly, DPI is important.

I hope more people find this useful and can learn from my mistakes.
As an old school game player, it is really hard for me to get on the touch control kind of stuff, specially for an action game like mine.
I´m still not quite 100% satisfied with my results, but they are now far better then when I started.

[fuzzy70]

I agree with you Erico, DPI was the realm of print mainly for quite some time. In the good old days everything had a 4:3 aspect ratio with regards to computers & TV's. Resolution caused some issues (think C64/CPC/BBC Micro) in that when you wanted to use more than one colour the horizontal resolution normally halved.

Then 16:9 widescreen came out for TV's & some reason PC's adopted the 16:10 ratio (although most are 16:9 now but not 100% sure).

It's all a conspiracy to keep us on our toes 

Lee

[spacefractal]

Also don't forget those damn sidebars on android, which are not covered in glbasic. They allways shave some pixels, which you cant use, because you often cannot hide them.

Example on Sony Xperia Z, the sidebar shown on the right side, which meant you only have 1794x1080 resoulution to been used on that phone. Its will look something like this (downscaled by two):


So you can't really hardcoded them into your game on Android at all, and you dont known the reported resoulution at all you get (and even the screenshot show a early bug in the game).

My best take is either to do scaling with any ratio in mind (as im did in Greedy Mouse), or doing that in example 4x3 and 16x9 in mind, and then use sideborders as excellent used in Snake Slider.

[erico]

I see what you mean space...but on the sansung fones, like note 2 or galaxy sx....I se no borders taken...really weird! Works out fine.

Qould this be related to android versions or fones shoveware?

....I hate touch keyboards...excuse me on the typos and crap english

[spacefractal]

Those side borders are related to Android versions, some times company too (example Amazon). They might or might not shown on various device. You cannot trust, if they can removed or not. Sidebars is not reported back to the app, so you are just get the screen area resoulution you can use.

Here in my home, the sidebar is shown on the bottom on a Samsung Tab2 (which seen its default placement), but not on HTC Desire HD. On the Sony Xperia Z, which my friend have (that why the older screenshot), its can even been placed on the right side (which im have not seen that before).

[fuzzy70]

I would hazard a guess that those side bars only appear on tablets/phones which have no physical Home/Back/Menu etc buttons as that is what is shown in your screenshot.

I have never seen a sidebar like that on my Wildfire S, Old Galaxy 1 & my friends S3 & S3 mini, probably because they all had physical controls on the phone.

Knowing what has or has not got physical buttons would be a nice addition to that website you linked Erico 

Lee

[spacefractal]

Yep, there is many devices without those buttons. That why your game only report the screen area you can use, not the full area.

It's annoying, because they breaks 16:9, 4:3 thing, which would scale so nice. Property it's can been fixed by use some sort of sideboarders like snake slide, or design with any resoulutions in mind (like my games).

It's a headchace for Android for sure, here it's easier for iOS as well WebOS.

[erico]

Thank s guys. I didn't know about it. My last design kinds of take that onto account.
...specially considering i had designed it for a caanoo...ye no touch but safe areas on its dead pixels.

All that takes screen space

[erico]

I kind of see what Space meant about the sidebar now and the issues with a no-real-buttons phone.

Maybe some of them have a standard resolution and you have to work with a safe area?
My game´s safe area is caanoo related, but I wonder if GLB will return the full screen on these phones or the already cropped area considering the sidebar?

If it is the former, the better. You can count off those pixels on both sides for the more important stuff on your game, like hud and so on.
If it is the latter, then I guess it will be a bit hard to have stuff centralized properly.

I must try my game on a phone like that.

But one issue I get from my note II, is that the buttons are flat and part of the glass covering the whole phone.
My controls are placed on both sides (2 buttons each one on top of each other) in a similar fashion to Spacefractal´s Karma Miwa.

While playing, when things get really tough, you can accidentally touch the menu or the back button while berserking.
Menu does nothing, but the back button ejects off the app instantaneously.

The middle note II´s button is a real-press-button, so there is no problem with that one.

[mentalthink]

Thanks Erico this comes very usefull, so if you need make renders for the devices you know exactly the output of the render...
Thanks for the info

[spacefractal]

Im thinks I in androidextras, back does no longer exit the game.

Sidebars is not counted when sdl create the surface. You get the screen area you have as the resoulution (checkout the old Karma Miwa screenshot, that was the returned resoulution I'm got from a Xperia Z).

Ps. On some systems it's might been possible to hide the taskbar, so it go a more quiet mode, but that require a higher API for that.