How do I keep the scalemode on GUI items such that when the player goes fullscreen at a different resolution format? (i.e. the application is intended for 1024x768, but fullscreen on a 1600x900 monitor stretches the GUI)
Also, will screenspace coordinates for pseudo buttons remain the same? I’ve got several GUI elements which are simply textures drawn on the screen and only exist as a visual indication that it’s intractable, but the behavior is controlled via mouseDown and mouseDrag events within a rectangle (that lines up with the texture). It would be inconvenient if the texture scaled up 30% but the faked button area did not.
i change the size of it based on the screen with and height
That’s not really an option here. I’ve got…25 textures being drawn to the screen using both Graphics.DrawTexture (I cannot use GUI.DrawTexture, as I need to specify a material in order to do alpha threshold clipping) and GUITextures attached to an empty object, plus some GUIButtons (which in full screen mode don’t line up with textures drawn using the same coordinates!) and several “mouse collision rectangles” (13 of them? No 16).
Due to them all using slightly different screen coordinates, it’s not feasible to calculate how to re-scale them depending on the resolution of the monitor (for example, the GUI textures and the Graphics.DrawTextures are both stretched horizontally on a widescreen monitor, for no apparent reason, and altering their scale would then force an alteration in their position as well as further alterations to the rectangles where mouse events occur!).
Get EZGUI lol. I just got it and its amazing. Its way faster and very easy to line things up the way you want. And it will stay the same across multiple platforms
For the low, low price of $199!
Not to mention the extra hours spent rewriting all of my scripts and trying to learn how to apply gui element styles to a new syste. Yeah, no. I don’t think that’s going to fly.
Pick your “target resolution” which is the screen space you want to express your position rectangles in. Then, get the actual screen space, divide for scale, and set a scaling matrix in to GUI.matrix. You may want to do relative positioning (ie elements calculated from screen edge or center) so that things move around appropriately when the aspect ratio changes.
You could use similar matrix scaling for your DrawTexture calls.
Here’s some code snippets from the class I use for this:
// call in Update to allow editor to rescale as needed
static function init()
{
screenWidth = 480.0; // target screen space is 480x320
screenHeight = 320.0;
screenXScale = Screen.width / screenWidth;
screenYScale = Screen.height / screenHeight;
var scaleVector : Vector3 = Vector3(screenXScale,screenYScale,1);
screenMatrix = Matrix4x4.identity.Scale(scaleVector);
}
// call in OnGUI
static function correctScale()
{
GUI.matrix = screenMatrix;
}
// use this rect to anchor to the right top
static function fromRightTop(x : int, y : int, width : int, height : int) : Rect
{
return new Rect(screenWidth - width - x, y, width, height);
}
Hope I read your question correctly and this helps!
What if I said I didn’t want the graphics to scale? What if I wanted my UI elements to be of a fixed size, but as the screen gets larger (or smaller, although we are building for 1024x768, so it’s unlikely that it will be used at a smaller size) the “center” visible area (the 3D world) gets larger and the screen elements simply move apart?
The big issue is that it appears that GUITextures (a gameobject component) is automatically scaled to screensize (stretched, rather than scaled to fit) without any code being applied.
The rectangles I use to detect mouse location (such as: if(event.type == eventtype.mousedown Rect(x,y,w,h).contains(event.mouseposition){} ) are also scaled or translated in some manner, as they are NOT behaving as expected when the graphical element that represents Rect(x,y,w,h) hasn’t been scaled.
Edit:
It’s hard to explain this, and screenshots in fullscreen unity are not 1:1 with the monitor, but 1:1 to unity’s intended size.
Here: http://tipmedia.com/demos/virtual/anatomy.html
The joystick-thing in the lower left has the most number of issues between full screen and not, as it’s using the standard asset (mobile) → joystick script, which uses a GUITexture component. In fullscreen it will distort, and the mouse-interaction was hacked into the script in place of touch locations, so it’s coordinates are off when the fullscreen resolution doesn’t match the intended resolution.
The Layers button (there’s actually an invisible GUI.Button under the upper left toolbar-thing–largely speaking the buttons are unaffected, but do appear to be slightly taller than they should be) will open a set of slider controls. These coordinates are also wrong when in full screen as well.
If you’re stuck, there’s a workaround I imagine would work. Generate two builds of the file, one at 4:3 (640x480) and the other at 16:9 (640x360) aspect ratios. When a widescreen player is open in fullscreen mode on a widescreen monitor, the graphics seem to maintain their proportional sizes and don’t appear stretched. The same holds true for a standard ratio player and monitor.
If accessed through a webpage, include javascript that calculates and redirects them to the standard or widescreen version. And if using standalone do something similar, there should be .NET code that allows you to figure out the user’s monitor aspect ratio, so maybe write a small C# launcher script that opens the appropriate version.
That doesn’t cover “strange” monitor sizes. I.e. 16:10 (the monitor I use Unity on is a 16:10; 1920 x 1200)
Nor does it cover the oddness of the mouse detection rectangles not being where they should be. It appears as if full screen mode sets the monitor’s resolution to the application’s intended resolution (for the rendering appears jagged and pixelated and the mouse gets larger) but the rectangles don’t line up with the graphics (and using Screen.height modified by an offset didn’t help: one of the rectangles, which would be 80 pixels above the bottom edge of the screen and 25 pixels high, is actually 15 pixels above the bottom edge and extends down below*).
*Also, when drawing a graphic at Rect(a,b,c,d) and then detecting the mouse in Rect(a,b,c,d) the two don’t line up. Turns out this is a bug in the player.