I'm getting into app/game development for android and I just wanted to know how hard it is to make your games work with all phones. or do the phones just scale the app to fit with the screens? thanks for any help
Screen resolution isn't as big a problem as the differences in screen ratios and defining things like touch-area sizes.
The commonest devices that my games and apps are running on have the following sizes...
320x480 (4x6)
480x800 (3x5)
480x854 (it defies belief to try to give a ratio to that nonsense)
I use AndEngine and libgdx - both will scale automatically BUT I have to choose a ratio to work with and it will crop (with black bars rather than lost content) on devices which don't share that ratio (for reference I choose to crop lower-resolutions as I think people with nicer screens would complain sooner!!)
Actual physical screen sizes vary too - and you have to bear-in-mind that a box which may seem big enough to hit on a 4.3" high-density phone could be near-impossible to hit on a smaller/lower-density device...
Both of those things are far more worrying than scaling...
You should remember that screen resolution is only one of many factors deciding about game compatibility.
I think this video is a good for start
http://www.google.com/events/io/2011/sessions/building-aggressively-compatible-android-games.html
Related
I have a recycler view on my android app main page that displays a list of pictures and I can't decide which width to give my images so that they are not too heavy but still very neat. (My images take the whole width of the screen.)
I know every Android device has a different format but I need a one-size-fits-all.
I currently have images on my res folder with width 500px (and approx. 350px height). The images weight between 30ko and 100ko. But I must admit they are not very neat ...
So I guess I have to pack pictures with a greater width to gain quality, but I have no idea how much.
How does Instagram does it ? Pictures are always very neat, how do they do this ? What are the characteristics of their pictures ? I guess they weight a ton, no ? (like 500ko per image ?) or am I wrong ?
There are utilities ('Image Optimizers') that shrink jpeg images without any significant quality loss, you can find some of them on Google for manual use.
When showing a lot of images, you can use a library such as Compressor to do this for you. I believe that apps such as Instagram might have their own code but same same. The file sizes are usually 15-300 kb, depending on the 'complexity' of the image.
After spending quite some time testing on different sizes and weights, my conclusion is that 500px wide images are not displayed very well on devices in general when you want to have image that take the whole width of the phone. But you can have light images (between 30Ko and 80Ko).
Below 500px width is not a good idea.
When you go up to 1000px wide images, you get a whole better quality, that gives your app a better look and feel in my opinion. But obviously images are somewhat bigger (between 80 and 190Ko)
When you go up to 1500px wide images, you have to be careful to the weight of the image. I wouldn't recommand having images that weight more than 200 Ko. But at least you got very good quality ... which is something nice :D
I hope that could help
I am using Java with OpenCV Library to detect Face,Eyes and Mouth using Laptop Camera.
What I have done so far:
Capture Video Frames using VideoCapture object.
Detect Face using Haar-Cascades.
Divide the Face region into Top Region and Bottom Region.
Search for Eyes inside Top region.
Search for Mouth inside Bottom region.
Problem I am facing:
At first Video is running normally and suddenly it becomes slower.
Main Questions:
Do Higher Cameras' Resolutions work better for Haar-Cascades?
Do I have to capture Video Frames in a certain scale? for example (100px X100px)?
Do Haar-Cascades work better in Gray-scale Images?
Does different lighting conditions make difference?
What does the method detectMultiScale(params) exactly do?
If I want to go for further analysis for Eye Blinking, Eye Closure Duration, Mouth Yawning, Head Nodding and Head Orientation to Detect Fatigue (Drowsiness) By Using Support Vector Machine, any advices?
Your help is appreciated!
The following article, would give you an overview of the things going under the hood, I would highly recommend to read the article.
Do Higher Cameras' Resolutions work better for Haar-Cascades?
Not necessarily, the cascade.detectMultiScale has params to adjust for various input width, height scenarios, like minSize and maxSize, These are optional params However, But you can tweak these to get robust predictions if you have control over the input image size. If you set the minSize to smaller value and ignore maxSize then it will work for smaller and high res images as well, but the performance would suffer. Also if you imagine now, How come there is no differnce between High-res and low-res images then you should consider that the cascade.detectMultiScale internally scales the images to lower resolutions for performance boost, that is why defining the maxSize and minSize is important to avoid any unnecessary iterations.
Do I have to capture Video Frames in a certain scale? for example
(100px X100px)
This mainly depends upon the params you pass to the cascade.detectMultiScale. Personally I guess that 100 x 100 would be too small for smaller face detection in the frame as some features would be completely lost while resizing the frame to smaller dimensions, and the cascade.detectMultiScale is highly dependent upon the gradients or features in the input image.
But if the input frame only has face as a major part, and there are no other smaller faces dangling behind then you may use 100 X 100. I have tested some sample faces of size 100 x 100 and it worked pretty well. And if this is not the case then 300 - 400 px width should work good. However you would need to tune the params in order to achieve accuracy.
Do Haar-Cascades work better in Gray-scale Images?
They work only in gray-scale images.
In the article, if you read the first part, you will come to know that it face detection is comprised of detecting many binary patterns in the image, This basically comes from the ViolaJones, paper which is the basic of this algorithm.
Does different lighting conditions make difference?
May be in some cases, largely Haar-features are lighting invariant.
If you are considering different lighting conditions as taking images under green or red light, then it may not affect the detection, The haar-features (since dependent on gray-scale) are independent of the RGB color of input image. The detection mainly depends upon the gradients/features in the input image. So as far as there are enough gradient differences in the input image such as eye-brow has lower intensity than fore-head, etc. it will work fine.
But consider a case when input image has back-light or very low ambient light, In that case it may be possible that some prominent features are not found, which may result in face not detected.
What does the method detectMultiScale(params) exactly do?
I guess, if you have read the article, by this time, then you must be knowing it well.
If I want to go for further analysis for Eye Blinking, Eye Closure
Duration, Mouth Yawning, Head Nodding and Head Orientation to Detect
Fatigue (Drowsiness) By Using Support Vector Machine, any advices?
No, I won't suggest you to perform these type of gesture detection with SVM, as it would be extremely slow to run 10 different cascades to conclude current facial state, However I would recommend you to use some Facial Landmark Detection Framework, such as Dlib, You may search for some other frameworks as well, because the model size of dlib is nearly 100MB and it may not suit your needs i f you want to port it to mobile device. So the key is ** Facial Landmark Detection **, once you get the full face labelled, you can draw conclusions like if the mouth if open or the eyes are blinking, and it works in Real-time, so your video processing won't suffer much.
I am looking to support a devices (TVs, tablets , phones)
I have the following directory setup.
res/layout/
res/layout-small/
res/layout-large/
res/layout-xlarge/
I expected layout-xlarge to target only TVs but it seems to target my 10 inch tablet as well.
Can anyone tell me why this is?
Should I try using the screen width directory structure/
e.g. res/layout-sw600dp etc.
Using '-small', '-large', etc, targets the resolution. So a small device with a high DPI would count as an '-xlarge' (For instance, the Nexus 5).
The correct way to do it, as you said, is to use the dp structure (-sw600dp, as you said).
dp in Android is a unit for density independent pixels:
What is the difference between "px", "dp", "dip" and "sp" on Android?
Using 'tvdpi' might be a good idea for targetting TV's as well.
Here is a good resource for this information:
http://developer.android.com/guide/practices/screens_support.html
I use the following:
-sw320dp (or default) for smaller phones
-sw360dp for regular phones
-sw480dp for huge phones
-sw600dp for 7" tablets
-sw720dp for 10" tablets
You can also specify pixel densities, such as -ldpi, -mdpi, -hdpi, -xhdpi, and -xxhdpi.
Here's a screenshot from one of my projects. Here, I attempt to provide the perfect images for all screen sizes and densities. This may be overkill for what you are trying to do.
For more information, please see http://developer.android.com/guide/practices/screens_support.html
I am working on a photobooth type app for iPhone and Android. On iPhone, I know the exact resolution of the front camera, and am able to always output 4 mini pics predictably and make a photostrip from them. But for Android, I need a way to resize 4 images I have taken to a width of 48px and height of 320px per image. This way, I can build the same size photostrip I built for the iPhone version, and easily display the photostrips in a consistent manner on a website (I don't want the size of them to vary depending on platform). On Android, how can I resize to that resolution (48x320), even if the Android camera doesn't output that aspect ratio? Basically, I'd like to resize on Android, and have it automatically zoom as necessary until 48x320 is reached and it doesn't look stretched/distorted...I'm ok with part of the image (like the outside border) being lost in favor of getting a 48x320 image. Maybe this is just a straight Java question...
Thanks so much!
I am developing a 2D platformer game for the android platform, so I don't really care about the screen DPI, but much more about the actual resolution in pixels. From what I've gathered on the net, there are a couple of different resolutions (and aspect ratios) present. According to my search, the two resolutions that are currently widespread are 480x320 (1.5) and 800x480 (1.666), is that right? I'd like to target these two resolutions to reach most customers.
Now, I can deal with the different aspect ratios by showing a black border of 40 pixel for the bigger display, essentialy reducing it to 720x480 pixel and a ratio of 1.5.
The problem with my game is that it is essential for gameplay that the players see the same amount of the world on each screen. Otherwise, some players would get an unfair advantage. Furthermore, I trigger some events depending on the visibility. For example, an enemy is only allowed to start shooting when the player starts seeing it. Otherwise, the enemies' bullets would seem to come from nowhere.
So I figured I need to either create my graphics for one resolution and scale them for the other. Or I create separate graphics for each resolution. Is that right? Unfortunately, both ways are suboptimal for pixel graphics.
On another note: How can I restrict my game to these resolutions only (especially for the Android Market)? I know about the "supports-screens" tag in the manifest, but that works depending on the effective screen-size, not the size in pixel, or am I mistaken?
I am also interested in personal experiences of other android game developers when it comes to resolution independence.
Thanks!
My question would be: what do you think would do on a PC? For game development, Android should be looked at much more like a PC target than a console. You just intrinsically need to accept that there will be some diversity of screens that you can't totally predict up-front.
So I think there are two main approaches to take:
(1) Use a constant "display size" as if you were setting a fixed video resolution on the PC and letting the user's monitor deal with it. On these devices of course there is no monitor, just one fixed display, so it doesn't make sense to modify the core resolution. Instead, you can set up the SurfaceView showing your game to have a fixed resolution, and let the platform's compositor take care of scaling it (in hardware) as it composites to the screen.
(2) More intelligently adjust to the actual resolution of the screen you find yourself running in. Scale up or down graphics yourself to create the playing area you want. Maybe have some different sizes of textures and select the appropriate ones for the screen resolution.
You could probably also do a combination of these, where you have a couple fixed sizes you pick for the surface view depending on the total resolution available which the game can run well with. In either case, you can do letter-boxing as appropriate to keep your aspect ratio constant on different screens, if that is what you want.
There are three approaches to differences in aspect ratio:
Show opaque borders on some ratios ("letterboxing").
Show more of the game world on some ratios.
Don't work at all on some ratios.
With approach (1) you waste screen space on some devices. Not such a big deal for televisions, but miserable on handheld devices where screen space is limited. With approach (2) players on some devices get advantages (they can see more of the world) and disadvantages (sprites are smaller, so touch precision is harder). Approach (3) just sucks.
Obviously it depends on the details of your game which is better, but as a player I much prefer approach (2). The constituency who care if players on other devices get a bit of a hypothetical advantage is pretty small compared to the constituency who care if their screen is partly obscured by unnecessary black bars.
(Similar approaches and remarks apply to differences in resolution.)