Develop Reference

How to adjust the screen for portrait and landscape mode such that all UI elements can be seen?

I am building an app.I have kept my reference resolution game view setting as (800 x 1200) .Settings for canvas shown below
When I check the it Iphone6(750 x 1334) resolution I can see the contents but certain components are cropped with respect to width.The Game view is shown below. I use panels,vertical layout group,horizontal layout group many UI components in my application.
Now I changed my Game view resolution to ipad pro(2224 x 1668).Now I cannot see my images.The Game view is shown below
I dont know how to adjust the UI elements according to different screen sizes.Some of the answers I observed was I should keep settings as Scale with screen size,match width or height and Match slider to 0.5. I have kept these settings(see first image).Still it is not changing according to different screen sizes.
I tried Aspect ratio fitter inside the parent element(Showdata) but of no use.What should I do to change screen according to different screen sizes?Is it because I am not anchoring UI elements in a proper way?
How will you anchor something like this(Canvas>Panel(Stretched along XY)>Panel(with Vertical layout)>Many UI elements)
I have seen many tutorials on how to use anchor for images and buttons but how to use for nested elements or when we use vertical or horizontal layout and it contains many UI elements.
The Rect Transform for each UI element is given below.

Here is an abbreviated list of tips, from most to least urgent:
Set your canvas scaling to Constant Physical Size. On iPhone X devices, the scaling factor is 3x. Find other physical scale factors here. The purpose of doing this is to make your Canvas's layout coordinates correspond to device points while rendering at the native resolution of the device. This is the most urgent source of your agony.
For RectTransform components corresponding to a full screen, set its anchors to (0, 0), (1, 1), i.e., fill the parent. Play with the Top, Right, etc. properties. But it seems like you already know that.
Child elements of vertical / horizontal layout groups should have a LayoutElement and should generally be of fixed size in the non-scrolling axis, i.e., do not use ContentSizeFitter on rows for now, get it to work for a fixed height. This is almost always the correct behavior on mobile devices anyhow.
Experiment with LayoutElement's Ignore Layout flag.
Correctly set the Pixels Per Unit setting on your textures.
On mobile devices, you will miss issues like cutouts and bevels in corners. Use NotchSolution for Unity 2019.2 and earlier, and the new Device Simulator for 2019.3 and above, to visualize and adapt to these issues.
Use a recycling scroll view component, like Optimized ScrollView Adapter. This will also include thoughtful tutorials about how to lay things out. If you need content fit height elements in a recycling scroll view, you will need this asset.
To generally trigger changes based on screen layout, use OnRectTransformDimensionsChanged(). Nothing else, don't check for changes in Screen! You should familiarize yourself with the EventSystem generally.
Familiarize yourself with the aspect ratios of various devices, and use Camera.main.aspect to correctly toggle between hand-tuned layouts for these aspect ratios. There are 4 in iOS.
Here is an example of a platform canvas scaler:
using UnityEngine;
using UnityEngine.EventSystems;
#if UNITY_IPHONE
using UnityEngine.iOS;
#endif
using UnityEngine.UI;
namespace StackOverflow
{
[ExecuteInEditMode]
public sealed class PlatformCanvasScaler : UIBehaviour
{
public static PlatformCanvasScaler instance { get; private set; }
public float scaleFactor
{
get
{
if (m_CanvasScaler != null)
{
return m_CanvasScaler.scaleFactor;
}
return 1.0f;
}
}
[SerializeField] private CanvasScaler m_CanvasScaler;
[SerializeField] private float m_PhoneScaleFactor = 1.15f;
private PlatformCanvasScaler()
{
instance = this;
}
protected override void Awake()
{
base.Awake();
if (!enabled)
{
return;
}
Refresh();
}
private void Refresh()
{
var scaleFactor = 1f;
var isMobile = PlatformCanvasScaler.isMobile;
if (isMobile)
{
#if UNITY_IPHONE
switch (Device.generation)
{
case DeviceGeneration.iPhoneX:
case DeviceGeneration.iPhoneXSMax:
case DeviceGeneration.Unknown:
case DeviceGeneration.iPadUnknown:
case DeviceGeneration.iPodTouchUnknown:
scaleFactor = 3f;
break;
case DeviceGeneration.iPhone5:
case DeviceGeneration.iPhoneSE1Gen:
case DeviceGeneration.iPhone5C:
case DeviceGeneration.iPhone5S:
case DeviceGeneration.iPhone6:
case DeviceGeneration.iPhone6S:
case DeviceGeneration.iPhone7:
case DeviceGeneration.iPhone8:
case DeviceGeneration.iPhoneXR:
case DeviceGeneration.iPhoneUnknown:
scaleFactor = 2f;
break;
case DeviceGeneration.iPhone6Plus:
case DeviceGeneration.iPhone7Plus:
case DeviceGeneration.iPhone8Plus:
case DeviceGeneration.iPhone6SPlus:
scaleFactor = 3f / 1.15f;
break;
case DeviceGeneration.iPhone:
case DeviceGeneration.iPhone3G:
case DeviceGeneration.iPhone3GS:
case DeviceGeneration.iPad1Gen:
case DeviceGeneration.iPad2Gen:
case DeviceGeneration.iPad3Gen:
scaleFactor = 1f;
break;
default:
scaleFactor = 2f;
break;
}
scaleFactor *= m_PhoneScaleFactor;
#else
scaleFactor = 2f * Screen.dpi / 326f;
#endif
}
else
{
if (Screen.dpi > 140)
{
scaleFactor = 2.0f;
}
else
{
scaleFactor = 1.0f;
}
}
m_CanvasScaler.scaleFactor = scaleFactor;
}
public static bool isMobile
{
get
{
var isPhone = false;
#if UNITY_IPHONE
isPhone = true;
#endif
var isMobile = Application.platform == RuntimePlatform.IPhonePlayer ||
(Application.isEditor && isPhone);
return isMobile;
}
}
#if UNITY_EDITOR
private void OnValidate()
{
Refresh();
}
#endif
// Update is called once per frame
private void Update()
{
}
}
}
Observe I make some decisions about what is considered a HiDPI device.
Unfortunately, my favorite UI asset for screen management, MaterialUI, is deprecated. Hopefully someone can comment on their experience with others.

Use x/y coordinates to set bounds of a moving particle

I have two bitmaps that I draw onto the center of a canvas:
One is only a background, it's a spirit level in top view which doesnt move. The second one is a bitmap looking like a "air bubble". When the user tilts the phone, the sensors read the tilt and the air bubble moves according to the sensor values along the x-axis. However, I need to make sure that the air bubble doesnt move too far, e.g out of the background-bitmap.
So I tried to which x coordinate the bubble can travel to,
before I have to set xPos = xPos -1 using trial and error
This works fine on my device.
To clarify: On my phone, the air bubble could move to the coordinate x = 50 from the middle of the screen. This would be the point, where the bitmap is at the very left of the background spirit level.
On a larger phone, the position x = 50 is too far left, and therefore looking like the air bubble travelled out of the water level.
Now I've tried following:
I calculated the area in % in which the air bubble can move. Let's say that
is 70% of the entire width of the bitmap. So I tried to calculate the two x boundary values:
leftBoundary = XmiddlePoint - (backgroundBitmap.getWidth() * 0.35);
rightBoundary = XmiddlePoint + (backgroundBitmap.getWidth() * 0.35);
...which doesnt work when testing with different screen sizes :(
Is it possible to compensate for different screen sizes and densities using absolute coordinates or do I have to rethink my idea?
If you need any information that I forgot about, please let me know. If this question has already been answered, I would appreciate a link :) Thanks in advance!
Edit:
I load my bitmaps like this:
private Bitmap backgroundBitmap;
private static final int BITMAP_WIDTH = 1898;
private static final int BITMAP_HEIGHT = 438;
public class SimulationView extends View implements SensorEventListener{
public SimulationView(Context context){
Bitmap map = BitmapFactory.decodeResource(getResources, R.mipmap.backgroundImage);
backgroundBitmap = Bitmap.createScaledBitmap(map, BITMAP_WIDTH, BITMAP_HEIGHT, true;
}
and draw it like this:
protected void onDraw(Canvas canvas){
canvas.drawBitmap(backgroundBitmap, XmiddlePoint - BITMAP_WIDTH / 2, YmiddlePont - BITMAP_HEIGHT / 2, null);
}
backgroundBitmap.getWidth() and getHeight() prints out the correct sizes.
Calculating like mentioned above would return following boundaries:
DisplayMetrics displayMetrics = new DisplayMetrics();
((Activity) getContext()).getWindowManager().getDefaultDisplay().getMetrics(displayMetrics);
int width = displayMetrics.widthPixels;
//which prints out width = 2392
xMiddlePoint = width / 2;
// = 1196
leftBoundary = xMiddlePoint - (BITMAP.getWidth()* 0.35);
// = 531,7
However, when I use trial and error, the right x coordinate seems to be at around 700.

I've come across a great explanation on how to fix my issue here.
As user AgentKnopf explained, you have to scale coordinates or bitmaps like this:
X = (targetScreenWidth / defaultScreenWidth) * defaultXCoordinate
Y = (targetScreenHeight / defaultScreenHeight) * defaultYCoordinate
which, in my case, translates to:
int defaultScreenWidth = 1920;
int defaultXCoordinate = 333;
DisplayMetrics displayMetrics = new DisplayMetrics();
((Activity) getContext()).getWindowManager().getDefaultDisplay().getMetrics(displayMetrics);
displayWidth = displayMetrics.widthPixels;
leftBoundary = (displayWidth / defaultScreenWidth) * defaultXCoordinates

360 panorama viewer with rajawali + VR howto change FieldOfView

I am trying to create a 360 image viewer using rajawali + vr (Cardboard toolkit).
When i disable the VR-Mode on the CardboardView the changes i made on Field of View property in the renderer has no effect.
in the Google Cardboard docs i found the the view will ignore it
For monocular rendering, the implementor should feel free to ignore the FieldOfView and instead create a perspective matrix with whatever field of view is desired for monocular rendering
My Question is how can i do this?
and where should i implement it, neither the renderer nor the CardboardView has a method to set an perspectiveMatrix (float[])?

updating the device param seems to always get overwritten by the gvr view
but if you decompile the FieldOfView class, you get this:
public void toPerspectiveMatrix(float near, float far, float[] perspective, int offset) {
if(offset + 16 > perspective.length) {
throw new IllegalArgumentException("Not enough space to write the result");
} else {
float l = (float)(-Math.tan(Math.toRadians((double)this.left))) * near;
float r = (float)Math.tan(Math.toRadians((double)this.right)) * near;
float b = (float)(-Math.tan(Math.toRadians((double)this.bottom))) * near;
float t = (float)Math.tan(Math.toRadians((double)this.top)) * near;
Matrix.frustumM(perspective, offset, l, r, b, t, near, far);
}
}

Vertical orientation degree - Android

Anyone knows how to get smooth vertical orientation degree in Android?
I already tried OrientationEventListener as shown below but it's very noisy. already tried all rates, Normal, Delay, Game and Fastest, all shown the same result.
myOrientationEventListener = new OrientationEventListener(this, SensorManager.SENSOR_DELAY_NORMAL) {
#Override
public void onOrientationChanged(int arg0) {
orientaion = arg0;
Log.i("orientaion", "orientaion:" + orientaion);
}
};

So there are two things going on that can affect what you need.
Sensor delay. Android provides four different sensor delay modes: SENSOR_DELAY_UI, SENSOR_DELAY_NORMAL, SENSOR_DELAY_GAME, and SENSOR_DELAY_FASTEST, where SENSOR_DELAY_UI has the longest interval between two data points and SENSOR_DELAY_FASTEST has the shortest. The shorter the interval the higher data sampling rate (number of samples per second). Higher sampling rate gives you more "responsive" data, but comes with greater noise, while lower sampling rate gives you more "laggy" data, but more smooth.
Noise filtering. With the above in mind, you need to decide which route you want to take. Does your application need fast response? If it does, you probably want to choose a higher sampling rate. Does your application need smooth data? I guess this is obviously YES given the context of the question, which means you need noise filtering. For sensor data, noise is mostly high frequency in nature (noise value oscillates very fast with time). So a low pass filter (LPF) is generally adequate.
A simple way to implement LPF is exponential smoothing. To integrate with your code:
int orientation = <init value>;
float update_rate = <value between 0 to 1>;
myOrientationEventListener = new OrientationEventListener(this, SensorManager.SENSOR_DELAY_NORMAL) {
#Override
public void onOrientationChanged(int arg0) {
orientation = (int)(orientation * (1f - update_rate) + arg0 * update_rate);
Log.i("orientation", "orientation:" + orientation);
}
};
Larger update_value means the resulting data is less smooth, which should be intuitive: if update_value == 1f, it falls back to your original code. Another note about update_value is it depends on the time interval between updates (related to sensor delay modes). You probably can tune this value to find one works for you, but if you want to know exactly how it works, check the alpha value definition under Electronic low-pass filters -> Discrete-time realization.

I had a similar problem showing an artificial horizon on my device. The low pass filter (LPF) solved this issue.
However you need to consider when you use the orientation angle in degrees and apply the LPF on it blindly, the result is faulty when the device is in portrait mode and turned from left to ride or opposite. The reason for this is the shift between 359 and 0 degree. Therefore I recommend to convert the degree into radians and apply the LPF on the sin and cos values of the orientation angle.
Further I recommend to use a dynamic alpha or update rate for the LPF. A static value for the alpha might be perfect on your device but not on any other.
The following class filters based on radians and uses a dynamic alpha as described above:
import static java.lang.Math.*;
Filter {
private static final float TIME_CONSTANT = .297f;
private static final float NANOS = 1000000000.0f;
private static final int MAX = 360;
private double alpha;
private float timestamp;
private float timestampOld;
private int count;
private int values[];
Filter() {
timestamp = System.nanoTime();
timestampOld = System.nanoTime();
values = new int[0];
}
int filter(int input) {
//there is no need to filter if we have only one
if(values.length == 0) {
values = new int[] {0, input};
return input;
}
//filter based on last element from array and input
int filtered = filter(values[1], input);
//new array based on previous result and filter
values = new int[] {values[1], filtered};
return filtered;
}
private int filter(int previous, int current) {
calculateAlpha();
//convert to radians
double radPrev = toRadians(previous);
double radCurrent = toRadians(current);
//filter based on sin & cos
double sumSin = filter(sin(radPrev), sin(radCurrent));
double sumCos = filter(cos(radPrev), cos(radCurrent));
//calculate result angle
double radRes = atan2(sumSin, sumCos);
//convert radians to degree, round it and normalize (modulo of 360)
long round = round(toDegrees(radRes));
return (int) ((MAX + round) % MAX);
}
//dynamic alpha
private void calculateAlpha() {
timestamp = System.nanoTime();
float diff = timestamp - timestampOld;
double dt = 1 / (count / (diff / NANOS));
count++;
alpha = dt/(TIME_CONSTANT + dt);
}
private double filter(double previous, double current) {
return (previous + alpha * (current - previous));
}
}
For further readings see this discussion.

(UNITY3d android game) When i don't touch the screen, my fps are lower than when i touch

I've had a problem for a long time with smooth camera on mobile phone (platformer game), but I reported that my game works well when my fps don't drop below 60. I notice that my fps are fine when i touch a screen, but when i don't do it, fps drop to approximately 58, 59 and after that my camera don't follow my player smoothly. For testing i create new scene with only FPSCounter script and the effects are the same. Could someone help me with it? I think that it is engine settings reasons, but i can't handle with it.emphasized text
//---------------------------------------------
// VARIABLES
//---------------------------------------------
private float deltaTime = 0.0f;
//---------------------------------------------
// METHODS FROM SUPERCLASS
//---------------------------------------------
void Update()
{
deltaTime += (Time.deltaTime - deltaTime) * 0.1f;
}
void OnGUI()
{
GUIStyle style = new GUIStyle();
float x = Screen.width - 110;
float fps = 1.0f / deltaTime;
Rect rect = new Rect(x, 90, 100, 50);
style.fontSize = 18;
style.normal.textColor = getColor(fps);
string text = string.Format("{0:0,0.0000 FPS}",fps);
GUI.Label(rect, text, style);
}
//---------------------------------------------
// CLASS LOGIC
//---------------------------------------------
private Color getColor(float fps)
{
if (fps >= 60)
{
return Color.yellow;
}
return Color.red;
}

Have you tried using the new UI system introduced in Unity 4.6? Maybe that fixes your issues.
https://www.youtube.com/watch?v=EOX6itCuKOc

As previously mentioned, you should really switch to the new UI system as the old GUI system was always a nightmare.
However, if you aren't wanting to switch, try setting more of your variables outside of OnGUI.
OnGUI is called multiple times per frame and it is expensive to set up a GUI style etc. so frequently - especially on an already poorly performing behaviour.