I have 2 android tablets - 1 samsung and 1 micromax tablet, samsung has 800 x 1280 pixels, 10.1 inches (~149 ppi pixel density) and micromax has 600 x 1024 pixels, 10.1 inches (~118 ppi pixel density).
I want their assets to be seprate but both are picking from mdpi, How can I do it?
Is it possible to use something like drawable-w600-mdpi and drawable-w800-mdpi?
No. Have a look at the Providing Resources page over at Android Developers. In Table 1 you can find all admissible qualifiers. Personally, I would suggest you let the OS handle the layout and choosing the right resource. However, with the new format of specifying resources 'wdp' respectively 'hdp', you might be able to get what you want as the tablets feature different sizes.
However, unless you have a very good reason to do so, I wouldn't do it. Often when you think you need to do something that is discouraged, there is a flaw in your design or the requirements can be met in an easier, more standard, way.
Update:
As by the comments, your problem is probably related to the devices not correctly communicating their DPI and, therefore, Android not choosing the correct resource. An Android Developer blog I recently read details the problem and shows a few examples on how to use the new numeric selectors tied to screen width and height to resolve some of those problems.
Related
I have a kha app that runs perfecly on an iPad2 (1024/768px).
When I run the same project on a later iPad Mini with 2048/1516. My coordinates are all half the size, which kinda makes sense.
So when I double all the sizes of my objects and GFX it will work on the iPad mini, but will be too big for iPad2.
I looked into a backbuffer and a renderTarget as explained here:
https://www.youtube.com/watch?v=OV1PTo5XSCA
There is also the windowSize option in khafile, which seems to do nothing.
Surface x and y coodinates always seem to come in in real screen coodrdinates of the device.
What is the best way to write a resolution independent app?
Perfect would be a way that is either retina or non-retina, depending on the device, where the code stays the same.
According to https://github.com/Kode/Kha/wiki/Screen-Size-and-Scaling there's automated scaling for some targets. If you need other targets you have to manually scale everything to fit the screen.
The page mentions using this class for the task: https://github.com/Kode/Kha/blob/master/Sources/kha/Scaler.hx
Also you could take a look at how Wyngine does it:
https://github.com/laxa88/wyngine/search?utf8=%E2%9C%93&q=scale & https://github.com/laxa88/wyngine/blob/master/Wyngine.hx
You replied (to my comment) that scaling wasn't enough. So far it was enough for all of my games with the right display settings, but if you really need retina sized graphics you always have the option of using multiple graphics sets. Eg:
a set for retina resultion (eg iPad 3)
a default resolution (eg iPad 2) set at half retina size
a low res set for cheap android devices?
At startup of your app you check the screen size. You use that to choose the internal game size and the graphics set that fits the actual screen resolution the best. The internal game size as well as all X/Y positions for the selected graphics set can be calculated by applying the graphics sets scale factor to the raw base values.
Finally you use Scale.scale() to scale your game from the internal game size to fit devices like the iPad pro 12" and the wide variety of Android devices.
That approach is common with a lot of game engines, google should find you links like https://v-play.net/doc/vplay-different-screen-sizes/ that also explain screen ratios and how those can be handled.
My first question on stackoverflow, so my apologies if I'm missing something.
I read in a reply in another J2ME transparency question from 2009 here at stackoverflow that "You should note that alpha is sometimes ignored on some implementations and sometimes quantized to ugly levels (Some motorola phones snap alpha values to the nearest 2-bit value)."
I am currently experimenting with transparency in J2ME, testing on rather new devices (at least in the J2ME world).
They all return 256 when I call Display.numAlphaLevels();
Yet, I only count max 8 actual levels (and mostly only 5 I can tell apart) when I set an image to slowly fade in.
And it seems it is, as the above quote states, the nearest 2-bit value:
1% visible at level 2-3
3% visible at level 4-7
6% visible at level 8-16
12% visible at level 16-31
25% visible at level 32-63
50% visible at level 64-127
100% visible at level 128-255
Tested on Sony Ericsson Aino, Vivaz, and a Nokia N8, with both an 8bit PNG and a 24bit PNG.
I consider those devices to be some of the latest models that can run J2ME.
The above quote makes it sound like it's not all J2ME enabled phones that behaves like this though. And that's why I ask my question:
Can anyone confirm that this is just how alphalevels are with J2ME enabled phones? If not, then how is it set up on other phones, and which phones are they?
Do you know of any J2ME enabled phone that actually have all the 256 levels? Or one that can give e.g. 75% visibility?
Thanks
Well, not quite sure what I did wrong, but apparently it was something in my test-code that gave me these wrong results, that just so happened to match a quote from another JavaME developer, which made the results seem probable.
Since I posted the question, the alphalevels suddenly appear as I'd like them to appear: Nice and smooth. Not sure what I've changed in the code, and too busy/lazy to test at the moment.
So this can be closed.
I'm making an app and I'm nearing completion, now I'm trying to optimize it for different screen sizes and pixel densities. One of the devices (using an emulator) is really frustrating me. I can't seem to find a qualifier that edits the Notion Ink Adam (1024x800 or something, 10.1 inches). According to this: http://developer.android.com/guide/practices/screens_support.html , Notion Ink Adam at 10.1 inches should be considered "xlarge" in a qualifier. However, when I use this in my qualifier like "layout-xlarge" the Notion Ink Adam emulator doesn't follow it.
I also tried using "layout-xlarge-hdpi" because I have another folder that's "layout-hdpi" that the Notion Ink Adam follows, but I'm using THAT qualifier for other devices. Also I've tried "layout-hdpi-long" but it also edits my other "long" hdpi devices. Notion Ink Adam is a tablet, and I'm just trying to seperate: 1) tablets like the Notion Ink Adam, 2)MDPI screens, the smaller screens, and 3) Long hdpi screens like the Nexus One and Motorola Droid.
My main problem is trying to find a qualifier that seperates 1 and 3, the tablet always follows my qualifier for the long hdpi screens.
Support for xlarge devices was introduced only in Android 2.3 (Gingerbread) and later. If your Adam is still running Froyo, it will report itself as "large" and will not find xlarge resources.
I developed an app, "ScreenInfo", which will cause an Android device to report its screen size and density classification. You can find it in the Market, or grab the source.
To help you sort out the various categories:
small-screened phones (like the original G1): normal-mdpi
most high-end smartphones w/3.7-4.5 inch screens: normal-hdpi
small-screened tablets (7-inch): large-mdpi, or in the case of the Galaxy Tab 7, large-hdpi
large-screened tablets (10-inch): xlarge-mdpi
As far as I'm aware, you're already doing everything correctly - using -xlarge for tablets, -hdpi, -mdpi, and so on for the appropriate screen densities, and so on. If the Adam's emulator (or the actual device) don't pull from the -xlarge layout already, it's probably in your best interest to simply ignore it. It's not a particularly popular tablet now that the Android 3.x devices are out (probably wasn't even before that, but I don't know), and if they're ignoring standards, all the more reason to ignore them in favor of what works for the majority of devices.
In terms of common qualifiers, I'm not sure what you mean, but if you go by the information in the documentation you linked, that's what's "common."
Adam reports itself as a large device. So, xlarge resources wont work on Adam.
I just ran my Android application on Galaxy Tab Emulator, where the design looks distracted. Now my worry is how to make the app fit perfectly on all the Tablet Screens. Since I came acrosss diffrent screen resolutions for Android Tablets.
For example:
Samsung Galaxy Tab 10.1 3G - 10.1 inches, 1280 x 800 pixels
Samsung P1000 Galaxy Tab - 7.0 inches, 600 x 1024 pixels
Dell Streak 7 - 7-inch 800×480
Motorola Xoom - 10.1-inch, 1280×800
Viewsonic G - 10.1-inchs 1024×600
For small, medium, large .. screens Android provides specific layout and drawable folders.
For tablets xhdpi and xlarge has been introduces. But still my question is how to make the design reliably compatible for all different tablet screen resolutions.
Look forward to your views/suggestions.
Thanks.
I came across Using new size qualifiers in the Supporting Multiple Screens documentation.
According to this you can create folders like this
res/layout/main_activity.xml # For handsets (smaller than 600dp available width)
res/layout-sw600dp/main_activity.xml # For 7” tablets (600dp wide and bigger)
res/layout-sw720dp/main_activity.xml # For 10” tablets (720dp wide and bigger)
this in combination with the xhdpi folder should give more granularity.
UPDATE
i came across this as well, though this is off the topic I think might be useful in some cases
res/layout/mylayout.xml # Default layouts
res/layout-v4/mylayout.xml # Android 1.6 layouts
res/layout-v11/mylayout.xml # Android 3.0 layouts
this link has a useful tip as well regarding using layout-v approach
I'm making an app but I don't wish to support retina display. The bad thing is that my app looks all pixelated. It's possible to deactivate the retina display feature ? So that my texture's proportions won't be doubled.
The scale property of UIScreen is read only and it's value is 2.0 in iphone 4, I would like it to be 1.0, so that my graphics in the iphone 4 looks exactly the same as older devices, without pixels.
The scale property of UIScreen is telling you that there are physically twice as many pixels in each direction on the retina screen.
You should not need to do anything special to get the app to appear the same on the retina display.
It will look slightly better if you provide #2x images though, and it may look more pixelated next to apps that are running at full resolution on the same device if the #2x images are not present.