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.
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.
When using "setMinimumHeight(...)/setMinimumWidth(...)" what units are the arguments in? I'm not turning up anything online, the book I bought doesn't address it and based on my experiments the units certainly aren't pixels. Thanks in advance.
Those parameters are measured in pixels, but there are other things at play here as well that unfortunately are harder to deal with and may be complicating your measurments.
Take a look at the following two images. The resolution of my screen remains at 3840x2160 but the "Scale Factor" that Windows suggests varies between 100% and 250%.
Scale Factor = 100%
Scale Factor = 250%
The ruler has actually changed size which could give you the impression that the size policy of these isn't equivalent to the pixel size. Note the size of each of these widgets starts at the grey, not at the blue. Additionally, even though Qt maintains the size of the widget in pixels independently from Windows' "Scale Factor", the same can't be said for the label in the center which does change in size depending on the scaling.
I don't know exactly how you are taking your measurements, what the GUI is, or what your display setting is, but those all can contribute to the confusion around sizing in Qt.
I'm using DirectX9 for rendering video output onto the screen .
The library used is SlimDX.
The software created is used for marking bad pixels from the output device so it's vital that no texture filtering / smoothing is done.
I disabled all the texture filtering options , disabled anti-aliasing , and aligned the texture to the screen at 1:1 ratio between the backbuffer and the rendered texture.
Thing is , on some devices , DirectX seems to be doing some bilinear filtering / blurring on the output.
I need all the output to be blocky , with -0- filtering.
Since all the resize code is operated on the control itself ( no backbuffer resizing etc' ) , I don't have the option of resizing the backbuffer.
Weird thing is , this only happens on some devices , not all.
How do I tell DirectX not to smooth what it renders to the control ? ( disable whatever texture filtering is done to the back/front buffer )
Thanks in advance for any help (:
For those who do not understand what I'm trying to get rid of -
when the resolution of the rendered image is lower than the resolution of the area drawn to , Direct3D creates a smooth transition between pixels.
What I want is for each pixel to be drawn as a simple rectangle , with absolutely no filtering , where can I find the settings that control this behavior?
I looked over it online , and it seems there is no proper explanation of this behavior anywhere .
What was going on :
The default DirectX behavior on WindowsXP and earlier was to smooth all rendering output ( if the control / screen you're rendering to isn't the exact same size as the backbuffer )
From WindowsVista onward the default behavior is to leave pixels as-is ( which basically means a stretched rectangle representing each pixel )
Since this is the behavior of the driver itself the user has absolutely no control over this :
The only solution is to reset the backbuffer each time the control is resized to conserve per-pixel rendering , there is no way around it - otherwise DirectX has control over the resizing technique
My graphics are looking blurry unless I add or subtract a half pixel to the Y coordinate.
I know this is a symptom that usually happens when the coordinates are set to sub-pixel values. Which leads me to believe one of my views must be off or something.
But I inspected the window, view controller and subviews, and I don't see any origins or centers with sub-pixel values.
I am stumped, any ideas?
See if somewhere you are using the center property of a view. If you assign that to other subviews, depending on their sizes they may position themselves in half pixel values.
Also, if you are using code to generate the UI I would suggest using https://github.com/domesticcatsoftware/DCIntrospect. This tools allows you in the simulator to look at all the geometry of visible widgets. Half pixel views are highlighted in red vs blue for integer coordinates. It helps a lot.
Is there a recommended smallest button size under normal conditions?
By "recommended" I mean prescribed by some document like:
Apple HCI Guidelines
Windows UX Guidelines
or some ISO standard..
By "normal" conditions I mean:
desktop/office use
standard 96dpi monitor resolution
mouse/touchpad for pointing (no touchscreen)
non-disabled or visually impaired users
standard "theme" (no large fonts/icons)
Microsoft's UX Guide for Windows 7 and Vista recommends:
"Make click targets at least 16x16 pixels so that they can be easily clicked by any input device. For touch, the recommended minimum control size is 23x23 pixels (13x13 DLUs)." where"A dialog unit (DLU) is a device-independent metric where one horizontal dialog unit equals one-fourth of the average character width for the current font and one vertical dialog unit equals one-eighth of the character height for the current font. Because characters are roughly twice as high as they are wide, a horizontal DLU is roughly the same size as a vertical DLU, but it's important to realize that DLUs are not a square unit."
You may also want to look up Fitts' Law, which calculates the time necessary to complete an action as a function of the target size. That can help mathematically determine the trade-offs of different button sizes.
Well, I try to make important/common mouse targets as large as possible without looking bad, something about 20 pixels (assuming 96 DPI) height, and as much width as needed to accomodate labels. If the button has no labels, which is very rare, I found out it's actually comfortable to have an aspect like 20w/50h (with the icon on top, not center), since the mouse is easier to move horizontally. So it's also good to keep them in the same row.
In addition to what MsLis suggested the UX Guide also suggests a minimum width of 75 pixels specifically for Command Buttons.
UX Guide - Recommended sizing and spacing