- Home /
Any way to have tap screen movement controls that ignore GUI Buttons for all aspect ratios?
So in my game I set custom rects for the PlayerMoveScript Update() function which give the specific positions and sizes for the GUI buttons. This allows the player to independently use both the GUI and the PlayerMoveScript systems during game play. Without this kind of artificially created system to ignore the GUI button commands while controlling the player movement the player would run to the position of the button press instead of just activating the button command.
So it works fine for 1280x720 and any 16:9 aspect ratio that I have been using 1280x720 for as well.
But now I'm trying to set it up with an iPad 4:3 aspect ratio and everything is a total disaster. I've been using a GUI.matrix to scale my GUI components but now it seems like I should have been using individual game objects with GUITexture components attached to them AND an additional scaling script for the different aspect ratios? Seems extremely excessive to do this for 100's of GUI textures.
Wish there was some way to position, size, and scale GUI stuff for tap screen movement controls without being a Houdini programmer status with escaping these horrible problems so easily.
So right now the only way I can think to do this is to use 1 aspect ratio to cover all the possibile resolutions for that aspect ratio and use custom coordinates for each aspect ratio in my PlayerMoveScript which corresponds to custom positions and sizes in the GUI.
At least the gameplay would work although I'll still have the problem of textures being warped out of proportion due to the GUI.matrix.
Do I need custom Textures for each aspect ratio? It seems if I designed GUI texture systems to perfectly fill the screen at 16:9 ratio there is no way to perfectly fill a 4:3 screen without warping the aspect ratio of those textures causing square ones especially to look quite goofy?
I guess my main question is there any way I can detect GUI button commands to control the PlayerMoveScript Update() stuff? It seems that GUI and Update are completely unrelated and can't be used correctly together for this kind of thing? I tried setting bools to not allow the player to be given movement commands when a GUI button is pressed, even tried doing some delays after GUI button presses with coroutines. However this seems to not work, at times the player movement commands seem to be executed before the GUI button presses.
Pretty discouraged right now, I have literally 10,000+ lines of GUI code in my project but I feel like I just pulled the biggest idiotic programming designs ever if it's all worthless for any other aspect ratios than 16:9. I think I could get this stuff to work just fine with different types of controls, but having both the player movement commands and GUI button presses both rely on screen tapping, there doesn't seem to be any way to do this other than setting custom sizes and positions for my Update() movement commands to ignore for every single aspect ratio? Seems like GUI system event type of stuff would be useless since it's not connected to Update at all?
Really trying to avoid doing so much custom calculations for every button that can be used in gameplay for each aspect ratio, even worst if I do it for each resolution :(
And that won't even solve the whole Textures are all warped thing unless they are 16:9...
Really wish Unity had better documentation and tutorials for this kinda stuff. I've been working on this project for like 9 months and doing my best to read everything and research this and I feel like my whole project is worthless except 16:9 not too happy about this situation...
This is what it looks like at 1280x720 (and all other 16:9 aspect ratios):
http://tinypic.com/view.php?pic=213odk&s=5#.Uqad0GRDv0h
This is what it looks like on the iPad 4:3 resolution using the GUI.matrix scale:
http://tinypic.com/view.php?pic=169l2k9&s=5#.UqaeGWRDv0h
In that last one you can see how the textures are warped when not using 16:9 aspect ratio. The square skill buttons are no longer square.
This is what it looks like on the iPad 4:3 resolution without using my GUI.matrix scale for 1280x720
http://tinypic.com/view.php?pic=v75h78&s=5#.Uqae-GRDv0h
Here I only disabled the 1280x720 scale for the Main Menu, potions, and skill buttons but you can see they are way too small and in the incorrect positions now.
Worst comes too worst I guess I would be forced to use the 2nd screenshot with the warped texture scales if at least the gameplay would be fine. But I was hoping I could do this with this kind of tap movement system directly from the button press instead of defining custom screen positions for every aspect ratio or resolution. It doesn't seem like this is possible since Update() is not synced correctly with OnGUI()?
And am I correct in thinking that a GUI display like this with sizes specifically set to fit perfectly for 16:9 would be impossible to display without all kinds of crazy warps @ 4:3?
http://tinypic.com/view.php?pic=ngsi1f&s=5#.UqagQGRDv0h
Geeze this whole thing is a huge headache this is by far the biggest problem I've had on this project so far despite trying so hard to understand how to do all this properly. Wish I had an iPad from the start so I wouldn't find out about this 10,000+ lines into my GUI coding :(
This is the first time I feel like I'm not gonna be able to handle this problem out of all the ridiculous things I've had to go through to get to this point haha.
A couple of things. Your code with GUI.matrix doesn't seem to preserve aspect ratio of GUI controls. Try looking at this solution. Alternatively, take a look at the Scale$$anonymous$$ode parameter for GUI.DrawTexture. Looks like adding ScaleToFit to your DrawTexture calls GUI.DrawTexture(myRect,myTex,Scale$$anonymous$$ode.ScaleToFit)
would be a good safety measure. As far as ignoring the GUI elements, you can also use GUI.enabled as an alternative to moving them out of the screen.
As far as your main question goes, you can move your code that sets a waypoint for the player in LateUpdate which gets run after OnGUI. Then you'd enable/disable it with an additional boolean which gets the value of GUI.changed for that frame:
var disable$$anonymous$$ovement:boolean=false;
function OnGUI(){
//gui code here
disable$$anonymous$$ovement=GUI.changed;
}
function LateUpdate(){
if(disable$$anonymous$$ovement==false){
//raycast and waypoint code here
}
}
Thanks for the link for the GUI.$$anonymous$$atrix scaling stuff! I'm taking a look at the code and it seems like it might work, I'll probably give it a go tomorrow!
The problem is a lot of my stuff isn't a GUI.DrawTexture, probably over 95% of it is using GUI.button and GUI.label with OnGUI()
So I'm not sure if the GUI buttons and labels can use the Scale$$anonymous$$ode stuff.
Another problem is that using the textures in general within OnGUI() is pretty much like random voodoo crazy powers to me. I don't understand it at all. Stuff like:
Setting textures to format = "true color" can make them the correct size.
Some Textures need to be "max size" = 2048 or they will be the wrong size.
Some Textures will be 64x32 in "Texture Type" = Texture with true color and they will switch to 57x25 when using "Texture Type" = GUI
None of this stuff seems to have the Scale $$anonymous$$ode "Stretch to Fill" option when inspecting the textures in the editor. They only have "clamp" and "repeat" for wrap mode, pretty worthless.
Even if I set my vector2 sizes to be public and try to manually adjust them in the editor, the scales don't work correctly it just uses the smaller of the two to scale the entire thing, SUPER ANNOYING.
So on that last point it looks like the link you posted might fix that, seems too good to be true but if it works that'd be amazing :)
But yeah I've tried to read all the Unity documentation for this stuff and I still have no idea how it works. It's all been trial and error for me, super annoying to work with this stuff.
And I'm not trying to make the elements disappear, I already have code for what should appear but it only looks the way I want it to @ 16:9 aspect ratios. I'm trying to ignore button presses that I do in OnGUI() on a separate scripts Update() function so it won't interfere with the player movement commands.
For example in the Update() when the player does any tap action on the screen before it can do anything it first must pass a series of conditions to make sure it wasn't on top of a button that could interfere with the player movement, cause them to lose their target etc. Like:
//when player taps it checks to make sure it's not on a buttons position so it won't interfere with gameplay
if (sprintButtonHitCheckRect.Contains(Input.mousePosition))
{
rayBool = false;
return;
}
else if ((swordButtonHitCheckRect.Contains(Input.mousePosition))
&& (playerHasSwordInt ==1))
{
rayBool = false;
return;
}
//if passes all conditions does raycast
So the only way I know how to get this to work right with both OnGUI() and Update() is to use the rects in the update before doing the player movement raycast stuff.
At least I found that I can use an empty game object with a GUITexture to accurately test and adjust the rect positions and sizes for all my buttons in the the Player$$anonymous$$oveScript Update()
Didn't feel like trying to figure all that out with math since the textures have such strange behavior especially when the scales aren't right.
Right now I'm just sticking to 1280x720 and 1024x768 for the only project resolutions, will try to add more later but this is super annoying and tedious.
And if some of the the GUI texture menus are sized to fit 16:9 perfectly and fill the whole screen with multiple textures lining up, I'm pretty much stuck with having wonky aspect ratios for everything other than 16:9 right?
O$$anonymous$$ so I just finished all the player movement stuff to ignore the button positions @ 1024x768.
$$anonymous$$ind of ironic how using the game object with GUITexture allows me to find the size and position for these at different resolutions without too much trouble when I probably should have been using those to begin with for all this stuff it sounds like?
Well anyways I'm in a lot less of a crisis panic mode right now knowing I can at least have the controls work right at different resolutions.
Setting the scale for all the textures is a whole new problem to think about now. But if I can at least get the controls to work based on any button positions/sizes and not have any problems working with both GUI() and Update() for gameplay I feel a little more safe moving forward now.
I'm almost tempted to just leave the GUI aspect ratios messed up for those who aren't 16:9, seems like too much work to try to fix it. But I'm sure my artist will be more critical of how it looks. I care a lot more about game play personally so any control problems freak me out to no end.
Here's what it looks like now screenshot directly from iPad this time. I also touched up a little bit of the player status bar problems by changing them to true color ins$$anonymous$$d of compressed for iOS, this fixed their size but I'm still not sure why I have to do that but things look better now.
You guys think it'd be worth redoing all the aspect ratios? $$anonymous$$ost devices will be closer to square buttons than this since 4:3 to 16:9 is one of the biggest differences right? I have a feeling my artist won't let me get away with that though haha.
So LateUpdate() runs after GUI every time? I thought it might run right before GUI or something since that's when the camera goes right? I thought about this a little and it would be worth a try for sure if it works.
Your answer
Follow this Question
Related Questions
Dealing with GUI size on iPhone 1 Answer
Scaling GUI When Screen Width is Adjusted 1 Answer
How to create a resizable GUI 1 Answer