koobas.hobune.stream
GUI - Scale GUIs According to Resolution
Hello,
I have a few GUIs in my game, and I'm trying to get it that the GUIs either scale up or scale down in size depending on my screen resolution.
By default, my GUIs stay the same size no matter what size my resolution is. I want to be able to scale them. So right now, I'm just starting with a simple texture that will scale:
function OnGUI(){
GUI.DrawTexture(Rect(100, 100, 100, 100), GuiTexture);
}
I believe I want to be using a 'GUI.matrix', but the documentation gives no, to little explanation on how to use it.
Also, the screen ratio that I am supporting is only 16:10, any ideas?
Thanks
Try this
C#
void OnGUI()
{
GUI.DrawTexture(ResizeGUI(Rect(100, 100, 100, 100)), GuiTexture);
}
Rect ResizeGUI(Rect _rect)
{
float FilScreenWidth = _rect.width / 800;
float rectWidth = FilScreenWidth * Screen.width;
float FilScreenHeight = _rect.height / 600;
float rectHeight = FilScreenHeight * Screen.height;
float rectX = (_rect.x / 800) * Screen.width;
float rectY = (_rect.y / 600) * Screen.height;
return new Rect(rectX,rectY,rectWidth,rectHeight);
}
Java
var GuiTexture : Texture2D;
function OnGUI()
{
GUI.DrawTexture(ResizeGUI(Rect(100, 100, 100, 100)), GuiTexture);
}
function ResizeGUI(_rect : Rect) : Rect
{
var FilScreenWidth = _rect.width / 800;
var rectWidth = FilScreenWidth * Screen.width;
var FilScreenHeight = _rect.height / 600;
var rectHeight = FilScreenHeight * Screen.height;
var rectX = (_rect.x / 800) * Screen.width;
var rectY = (_rect.y / 600) * Screen.height;
return Rect(rectX,rectY,rectWidth,rectHeight);
}
Sorry, I don't know C++, is it possible to do one in JS too? Thanks!
This works great, is it possible to apply this to a group? Ins$$anonymous$$d of having to redo all my GUI classes?
Okay, I've began doing that, but now my GUIs begin the lose their centering, so if the screen is small, the GUIs move the the upper left, and if its large, it moves to the lower right.
I know this question is quite old but I have been making a few games for Android and I used to use the answer given in your best answer.
IMHO using GUITextures with no Pixel Inset Values and using the Transform Position and Scale in the inspector has been the best way. Everything then auto scales much easier and the CPU Cycles saved Managed to get me an extra 10 FPS on low spec devices.
Rather than using set values you should base the size and position based on the Screen.width and Screen.height.
function OnGUI(){
GUI.DrawTexture(Rect(Screen.width/3,Screen.width/3, Screen.width/10, Screen.height/10), GuiTexture);
}
This will be the same relative size no matter what the end resolution is. I normally store the Screen.width and Screen.height values in variables for short, quicker reference.
Should state that when using lots of GUI objects, calling screen.width and screen.height a lot can slow things down considerably. It would be best to set them to variables and call those instead. It's even more important on things like mobile devices with slower processors.
You can also use a basic scaling system. Make your GUI with the optimal size, then multiply by a scale. Like this:
var optimalHeight:int = 1024; //just an example
var optimalWidth:int = 768;
var screen:Vector2;
private var scale:Vector2;
function Start()
{
screen = new Vector2(Screen.Width, Screen.Height); //width is x, height is y
scale = new Vector2(screen.x/optimalWidth, screen.y/optimalHeight);
//NOTE: We used small s on screen to not call the screen command again.
}
function OnGUI()
{
GUI.DrawTexture(
Rect(
100*scale.x,//left
100*scale.y,//top
(screen.x - 200) *scale.x,//width
(screen.y - 200) *scale.y)//height
, GuiTexture);
//The width and height are set up to use padding, so it will be 100pixels less
//then the width of the screen. (you have to include the size of the left side
//otherwise it goes to the edge of the screen)
//in this case, 100 pixel border on the texture.
}
This isn't tested, but it should work. This should work whether the scaling is larger or smaller then the optimal height and width. Hope this helps some.
Correct me if I'm wrong but the problem with the above examples would be that although it's resolution independent it's still aspect ratio dependent? I know he states he's only supporting "16:10" but wouldn't going to a 3D GUI solve screen resolution AND aspect ratio easier?
