Is there any way to force applying a phone UI to the Tablet and opposite? Since android 4.0 there is a possibility (by Android decision) to apply tablet UI's on the phones which is unacceptable.
Is there a way to strictly use only one kind of layout (phone or tablet), for example apply it by user decision (toggle switch or similar control)?
//use only one layout and use different drawables
res/layout/my_layout.xml // layout for normal screen size ("default")
res/layout-small/my_layout.xml // layout for small screen size
res/layout-large/my_layout.xml // layout for large screen size
res/layout-xlarge/my_layout.xml // layout for extra large screen size
res/layout-xlarge-land/my_layout.xml // layout for extra large in landscape orientation
res/drawable-mdpi/my_icon.png // bitmap for medium density
res/drawable-hdpi/my_icon.png // bitmap for high density
res/drawable-xhdpi/my_icon.png // bitmap for extra high density
Related
I am new in godot engine and I am trying to make mobile game (portrait mode only). I would like to make background image fit screen size. How do I do that? Do i have to import images with specific sizes and implement them all for various screens? If I import image to big, it will just cut out parts that don't fit screen.
Also, while developing, which width and height values should I use for these purposes?
With Godot 3, I am able to set size and position of sprite / other UI elements using script. I am not using the stretch mode for display window.
Here is how you can easily make the sprite to match viewport size -
var viewportWidth = get_viewport().size.x
var viewportHeight = get_viewport().size.y
var scale = viewportWidth / $Sprite.texture.get_size().x
# Optional: Center the sprite, required only if the sprite's Offset>Centered checkbox is set
$Sprite.set_position(Vector2(viewportWidth/2, viewportHeight/2))
# Set same scale value horizontally/vertically to maintain aspect ratio
# If however you don't want to maintain aspect ratio, simply set different
# scale along x and y
$Sprite.set_scale(Vector2(scale, scale))
Also for targeting mobile devices I would suggest importing a PNG of size 1080x1920 (you said portrait).
Working with different screen sizes is always a bit complicated. Especially for mobile games due to the different screen sizes, resolutions and aspect ratios.
The easiest way I can think of, is scaling of the viewport. Keep in mind that your root node is always a viewport. In Godot you can stretch the viewport in the project settings (you have to enable the stretch mode option). You can find a nice little tutorial here.
However, viewport stretching might result in an image distortion or black bars at the edges.
Another elegant approach would be to create an image that is larger than you viewport and just define an area that has to be shown on every device no matter whats the resolution. Here is someone showing what I am meaning.
I can't really answer your second question about the optimal width and height but I would look for the most typical mobile phone resolutions and ratios and go with that settings. In the end you probably should start with using the width and height ratio of the phone you want to use for testing and debugging.
Hope that helps.
I thought I had a grasp on auto layout, but when I test it on my 3.5 iPhone it does not look like a UI should.
The question is in the Simulated Metrics What should the size of the device be ? Inferred , Freeform , Detail ??
Keep in mind I am building for all iPhone models 3.5 , 4 , 4.7 , 5.5...
Thanks much.
JZ
I think, setting constrains through auto layout doesn't require you to concentrate on the Simulated Metrics. It could be freedom or fixed. What you need to know is your stimulator frame's size to calculate your component's contains.
For example, lets assume, you have an ImageView and you want that image view to consume 50% of your devices screen. You can use aspect ratio to do that but to calculate the ratio you need to know the stimulator's frame size.
If you select freedom, xCode will show you what is your stimulator's width and height. If it is 400X600 then you know that to be 50% of your screen size, your image view needs to be 200X300. So, you can then just go and set your constrains accordingly to make your image view look like 200X300 in your stimulator and then when you will test in any device, if you have set the constrains properly, you will have a constant behaviour.
I'm trying to learn SDL2. The main difference (as I can see) between the old SDL and SDL2 is that old SDL had window represented by it's surface, all pictures were surfaces and all image operations and blits were surface to surface. In SDL2 we have surfaces and textures. If I got it right, surfaces are in RAM, and textures are in graphics memory. Is that right?
My goal is to make object-oriented wrapper for SDL2 because I had a similar thing for SDL. I want to have class window and class picture (has private texture and surface). Window will have it's contents represented by an instance of the picture class, and all blits will be picture to picture object blits. How to organize these picture operations:
Pixel manipulation should be on surface level?
If I want to copy part of one picture to another without rendering it, it should be on surface level?
Should I blit surface to texture only when I want to render it on the screen?
Is it better to render it all to one surface and then render it to the window texture or to render each picture to the window texture separately?
Generally, when should I use surface and when should I use texture?
Thank you for your time and all help and suggestions are welcome :)
First I need to clarify some misconceptions: The texture based rendering does not work as the old surface rendering did. While you can use SDL_Surfaces as source or destination, SDL_Textures are meant to be used as source for rendering and the complimentary SDL_Renderer is used as destination. Generally you will have to choose between the old rendering framework that is done entirely on CPU and the new one that goes for GPU, but mixing is possible.
So for you questions:
Textures do not provide direct access to pixels, so it is better to do on surfaces.
Depends. It does not hurt to copy on textures if it is not very often and you want to render it accelerated later.
When talking about textures you will always render to SDL_Renderer, and is always better to pre-load surfaces on textures.
As I explained in first paragraph, there is no window texture. You can either use entirely surface based rendering or entirely texture based rendering. If you really need both (if you want to have direct pixel access and accelerated rendering) is better do as you said: blit everything to one surface and then upload to a texture.
Lastly you should use textures whenever you can. The surface use is a exception, use it when you either have to use intensive pixel manipulation or have to deal with legacy code.
I'm trying to set the 9 patch image attached below as my layouts background.It looks good on few device backgrounds and few devices shows consecutive circles in center which makes the UI inconsistent. I want consistent over all the device densities. How can I achieve the UI appearance on all devices being consistent?
It is difficult to understand what you mean.the grammar is a little bit unclear.do you mean the same background for all layouts?
Make sure you create versions of the 9Patch png for each density and put them in the relevant drawable folders (drawable-mdpi, drawable-hdpi, drawable-xhdpi etc).
When you run your app, android determines the screen density of the device you're running it on and then looks in that particular drawable folder for your 9Patch png. If it can't find a 9Patch png in the folder for that density, it will look in the folders for the other densities until it does find one. It will then either stretch or compress the png as needed to try and create a suitable png for the missing density. This stretching and compressing can lead to the sort of artifacts you are seeing.
For best results, don't leave it up to the operating system to try and generate images for missing screen densities. Provide your own images for each density.
Below is an excerpt from Supporting Different Screens on the Android Developers site. Take the time to read and understand this if you want to progress with developing apps for android, because this is fundamental to designing the look of any UI.
"..you should start with your raw resource in vector format and generate the images for each density using the following size scale:
xhdpi: 2.0
hdpi: 1.5
mdpi: 1.0 (baseline)
ldpi: 0.75
This means that if you generate a 200x200 image for xhdpi devices, you should generate the same resource in 150x150 for hdpi, 100x100 for mdpi, and 75x75 for ldpi devices."
I have to make the Android app with this screen (it'll be Android version of existing iOS app):
You can see that there're several images, buttons and text label in very specific positions relative to each other.
The problem is that Android devices are very various in screen sizes and dimensions. How to keep the elements' relative sizes on different screens?
Taking this picture as an example, I can calculate, for example, ratio between screen width and circle radius. However, how to keep this ratio with the multitude of Android screens?
You have to create multiple resources for your app. Android has 4 resolutions (ldpi,mdpi,hdpi and xhdpi) and 4 generalized screen sizes (small, medium, large and extra large). So you have to make 4 layouts (or 3 if you don't plan on supporting tablets, since tablets come under the extra large category) to support the screen sizes.
Here's a general guide:
put layouts for small, medium, large and extra large in your res/ folder as follows:
res/layout/sample_layout.xml // default layout
res/layout-small/sample_layout.xml // layout for small screen size
res/layout-large/sample_layout.xml // layout for large screen size
res/layout-xlarge/sample_layout.xml // layout for extra large screen size
you can also use
res/layout-land/sample_layout.xml for landscape orientation for all screen sizes or you can target landscape layouts for specific screen sizes as res/layout-medium-land/sample_layout.xml
note that all the layouts have the same name.
once you have your layouts ready, you need to take care of image resolutions also
once again in your res/ folder add images like this:
res/drawable-ldpi/sample_image.png // low density
res/drawable-mdpi/sample_image.png // medium density
res/drawable-hdpi/sample_image.png // high density
res/drawable-xhdpi/sample_image.png // extra high density
once again, all the images have the same name.
general guidelines for designing images are:
ldpi is 0.75x dimensions of mdpi
hdpi is 1.5x dimensions of mdpi
xhdpi is 2x dimensinons of mdpi
generally, I design mdpi images for a 320x480 screen and then multiply the dimensions as per the above rules to get images for other resolutions.
Android will automatically select the best combination of layout and image depending on the device. For example, for a high resolution medium size device, layout-medium and high density image will be displayed to the user.
Make sure you create emulators for all these combinations and test your app thoroughly. here's the official docs for more info:
https://developer.android.com/guide/practices/screens_support.html
For units of measurement, you can use density independent pixels (dp or dip) which will maintain your relative heights, distances etc across multiple resolutions in a stable fashion.