1
NGUI 3 Support / Re: Increase button collider size while pressed like iOS
« on: May 30, 2014, 05:34:19 AM »
Yeah I'm impressed you could make sense at all out of my rushed explanation lol
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
NGUI 3 Support / Re: Increase button collider size while pressed like iOS
« on: May 30, 2014, 05:18:06 AM »
Here's my new version that so far seems to do what I'm after. (Don't mind my silly style edits XD)
3
NGUI 3 Support / Re: Increase button collider size while pressed like iOS
« on: May 30, 2014, 05:01:05 AM »That's an awesome idea. I went ahead and made a simple script that does I think what you want. Just dump it on a button and it should be good to go. Feel free to do whatever you want to it (it only works with boxcolliders at the moment). The script however is still reliant on the mouse click threshold values you set on the UI camera, but now allows you to release while off the button, and still within those limits, and resizes back when you drag out of it.
Thanks man! I should probably look up exactly what iOS button behavior is again but I decided to comment out your drag related methods. That gives me what I think will work really well. I also like to set my mouse click and touch tap thresholds to infinity. Still have a lot of testing to do but I feel really good about it like this. Thanks for the help!
Edit: Ha yeah right away I think I'm seeing that I'll probably also need to have the button set itself to be in front of any adjacent buttons so it's now larger collider actually intercepts the ray. Shouldn't be hard to do.
4
NGUI 3 Support / Increase button collider size while pressed like iOS
« on: May 29, 2014, 10:02:09 PM »
In the past NGUI didn't have a behavior that I really wanted. In iOS when a button is pressed the collider, or whatever Apple might call it, increases in size as long as the finger doesn't stop touching the screen and is still over the collider.
This behavior really helps touch based applications feel better, especially if the buttons are many, small, and close together. Users constantly start touches inside small buttons just fine but have a hard time releasing their finger in just the right way as to keep the touch point inside the collider.
My question is: did NGUI ever have this feature added and if so how do I enable it? If not, what might be a good approach to scripting it up myself?
Said behavior in more detail: when a user begins touching over a button, the button's collider grows a given amount (generally adding about a half of a finger tip's width around the whole button). If the user drags off the collider it returns to normal size. If they drag back on to the (now normal size) collider it again grows until they drag back off of it or lift their finger anywhere. Lifting inside the collider of course fires the click event.
Thanks!!
This behavior really helps touch based applications feel better, especially if the buttons are many, small, and close together. Users constantly start touches inside small buttons just fine but have a hard time releasing their finger in just the right way as to keep the touch point inside the collider.
My question is: did NGUI ever have this feature added and if so how do I enable it? If not, what might be a good approach to scripting it up myself?
Said behavior in more detail: when a user begins touching over a button, the button's collider grows a given amount (generally adding about a half of a finger tip's width around the whole button). If the user drags off the collider it returns to normal size. If they drag back on to the (now normal size) collider it again grows until they drag back off of it or lift their finger anywhere. Lifting inside the collider of course fires the click event.
Thanks!!
5
NGUI 3 Support / Re: PixelPerfect and Atlas switching
« on: January 06, 2014, 07:55:56 PM »
Oh and the thing I think would totally put this to rest once and for all is if you added an example scene to NGUI that could be built to different devices and had working atlas swapping. Being able to see that all working end to end would be massively helpful, even if it was super basic, like you had to tell it in the editor if you're building for SD, HD, or SHD, etc instead of it detecting the device PPI or anything.
Might be a good idea to try this on real devices for yourself as well. You might be surprised by what you discover.
Might be a good idea to try this on real devices for yourself as well. You might be surprised by what you discover.
6
NGUI 3 Support / Re: PixelPerfect and Atlas switching
« on: January 05, 2014, 07:05:43 PM »
I really appreciate the effort to further explain atlas swapping.
I think the confusion here comes from the design of atlas swapping in NGUI being centered around keeping the widgets the same size relative to the UIRoot. I understand why that would seem to be the desired behavior. After all, the button on an SD iPhone and an HD iPhone should be the same size visually, right?
But if the UIRoot is scaling all the widgets so that they appear the pixel size dimensions from sprites in an SD atlas, then when the screen itself is HD, that widget will now be a quarter the size it should be. The widget can only stay the same size visually on a higher density display if either the widget size increases to match the pixels dimensions of the HD sprite, or the UIRoot scales everything relative to a lower resolution than the actual display.
The solution I found was to indeed set the UIRoot fixed size height to a lower resolution than the display actually is when using a higher resolution atlas.
From what I can gather, it appears most NGUI users don't try to use a pixel perfect design across different devices. Maybe for most developers it's not important but I do wonder how many of them don't use pixel perfect designs because they can't get a handle on the atlas swapping and widget size designs in NGUI.
Just some food for thought.
I think the confusion here comes from the design of atlas swapping in NGUI being centered around keeping the widgets the same size relative to the UIRoot. I understand why that would seem to be the desired behavior. After all, the button on an SD iPhone and an HD iPhone should be the same size visually, right?
But if the UIRoot is scaling all the widgets so that they appear the pixel size dimensions from sprites in an SD atlas, then when the screen itself is HD, that widget will now be a quarter the size it should be. The widget can only stay the same size visually on a higher density display if either the widget size increases to match the pixels dimensions of the HD sprite, or the UIRoot scales everything relative to a lower resolution than the actual display.
The solution I found was to indeed set the UIRoot fixed size height to a lower resolution than the display actually is when using a higher resolution atlas.
From what I can gather, it appears most NGUI users don't try to use a pixel perfect design across different devices. Maybe for most developers it's not important but I do wonder how many of them don't use pixel perfect designs because they can't get a handle on the atlas swapping and widget size designs in NGUI.
Just some food for thought.
7
NGUI 3 Support / Re: PixelPerfect and Atlas switching
« on: January 04, 2014, 11:34:04 PM »
Okay I think I finally found a work-around. Essentially all I do is set the fixed size to the screen height but then scale it exactly how the current UIAtlas pixel size would be if that property had an effect. Seems to work so far. Here's my code. It keeps the fixed size to the screen height even if it auto rotates and changes.
Oh and the logic here for checking device would need to be expanded on to either take into account more devices or be based on screen size.
Oh and the logic here for checking device would need to be expanded on to either take into account more devices or be based on screen size.
- using UnityEngine;
- using System.Collections;
- public class CorrectForDevice : MonoBehaviour
- {
- public UIAtlas referenceAtlas;
- private UIRoot uIRoot;
- private ScreenOrientation currentOrientation;
- private bool initialized = false;
- private float resolutionScale = 1f;
- void Awake()
- {
- uIRoot = GetComponent<UIRoot>();
- if( iPhone.generation == iPhoneGeneration.Unknown )
- {
- referenceAtlas.replacement = Resources.Load<GameObject>( "iPadRetina" ).GetComponent<UIAtlas>();
- resolutionScale = 0.5f;
- }
- if( iPhone.generation == iPhoneGeneration.iPhone5 )
- {
- referenceAtlas.replacement = Resources.Load<GameObject>( "iPhone" ).GetComponent<UIAtlas>();
- }
- }
- void Start()
- {
- currentOrientation = Screen.orientation;
- }
- void Update()
- {
- if( !initialized )
- {
- SetHeight();
- initialized = true;
- }
- if( Screen.orientation != currentOrientation )
- {
- SetHeight();
- }
- }
- private void SetHeight()
- {
- uIRoot.manualHeight = (int)((float)Screen.currentResolution.height * resolutionScale);
- currentOrientation = Screen.orientation;
- }
- }
8
NGUI 3 Support / Re: PixelPerfect and Atlas switching
« on: January 04, 2014, 09:29:18 PM »
Wow that's really interesting and honestly really disappointing. I love NGUI but atlas swapping is such a do or die feature that it really badly needs to be addressed ASAP.
To help demonstrate the issue at hand I've created a project that breaks the problem down. At the center of the problem, I believe, is the PixelSize property of UIAtlas and the fact that it simply doesn't cause any effect when loading an atlas at start up. (The problem that I believe electrodruid had to create an elaborate work around for.)
To illustrate PixelSize not causing any effect I've created 4 web player builds of a simple project.
The project does NOT have different resolution atlases. It simply has one real atlas and one reference atlas to show the effect of loading an atlas at start up. The widgets of course use the reference atlas and not the real atlas.
FixedSize UIRoot with UIAtlas PixelSize set to 0.5
FixedSize UIRoot with UIAtlas PixelSize set to 1
PixelPerfect UIRoot with UIAtlas PixelSize set to 0.5
PixelPerfect UIRoot with UIAtlas PixelSize set to 1
The project. (Add your own NGUI)
The different builds all have different pixel sizes and different UIRoot scaling styles.
Notice that none of the changes have any effect!
I don't see how there can be any correct way to use atlases if the PixelSize property doesn't cause ANY effect when loading an atlas at runtime.
Hope this breakdown helps isolate the issue here. Thanks!
To help demonstrate the issue at hand I've created a project that breaks the problem down. At the center of the problem, I believe, is the PixelSize property of UIAtlas and the fact that it simply doesn't cause any effect when loading an atlas at start up. (The problem that I believe electrodruid had to create an elaborate work around for.)
To illustrate PixelSize not causing any effect I've created 4 web player builds of a simple project.
The project does NOT have different resolution atlases. It simply has one real atlas and one reference atlas to show the effect of loading an atlas at start up. The widgets of course use the reference atlas and not the real atlas.
FixedSize UIRoot with UIAtlas PixelSize set to 0.5
FixedSize UIRoot with UIAtlas PixelSize set to 1
PixelPerfect UIRoot with UIAtlas PixelSize set to 0.5
PixelPerfect UIRoot with UIAtlas PixelSize set to 1
The project. (Add your own NGUI)
The different builds all have different pixel sizes and different UIRoot scaling styles.
Notice that none of the changes have any effect!
I don't see how there can be any correct way to use atlases if the PixelSize property doesn't cause ANY effect when loading an atlas at runtime.
Hope this breakdown helps isolate the issue here. Thanks!
9
NGUI 3 Support / Re: PixelPerfect and Atlas switching
« on: January 03, 2014, 11:48:20 PM »
I appreciate the instructions but they just don't work. I triple checked everything I have setup and I did it exactly how you describe. I assume we're supposed to be swapping atlases in Awake() via myAtlas.replacement? Because when I do that, it loads the atlas, but as electrodruid mentioned, the sprites end up staying the size they happen to be setup with so extra pixel density is lost as the size of the image does not increase in order to not appear smaller on a higher resolution screen. Follow? I tried both fixed size and pixel perfect and neither one helps because the sprites stay whatever size they were no matter what size atlas or what pixel size the atlas has set to it. It just feels like it's broken or bugged.
I think the issue may be here in UIAtlas.cs. Notice the comments above public float pixelSize:
/// <summary>
/// Pixel size is a multiplier applied to widgets dimensions when performing MakePixelPerfect() pixel correction.
/// Most obvious use would be on retina screen displays. The resolution doubles, but with UIRoot staying the same
/// for layout purposes, you can still get extra sharpness by switching to an HD atlas that has pixel size set to 0.5.
/// </summary>
Pixel size is apparently performed during MakePixelPerfect(). So if that function isn't being called on every widget using a replaced atlas, how is pixel size coming into play?
I think the issue may be here in UIAtlas.cs. Notice the comments above public float pixelSize:
/// <summary>
/// Pixel size is a multiplier applied to widgets dimensions when performing MakePixelPerfect() pixel correction.
/// Most obvious use would be on retina screen displays. The resolution doubles, but with UIRoot staying the same
/// for layout purposes, you can still get extra sharpness by switching to an HD atlas that has pixel size set to 0.5.
/// </summary>
Pixel size is apparently performed during MakePixelPerfect(). So if that function isn't being called on every widget using a replaced atlas, how is pixel size coming into play?
10
NGUI 3 Support / Re: PixelPerfect and Atlas switching
« on: January 03, 2014, 04:50:19 AM »
Did you ever find a satisfactory solution to this? ArenMook's suggestion to use a fixed size uiroot has me baffled. How is an iOS game with any screen rotation supposed to work then? After all, their screen height will change between portrait and landscape.
It's actually proving to be really difficult to find complete support for swapping different resolution atlases. All the examples I find leave the actual runtime implementation a total guessing game assuming you don't know NGUI as well as the developer that wrote it.
A real example that actually works on different devices would be very helpful assuming it doesn't leave out support for autorotation.
It's actually proving to be really difficult to find complete support for swapping different resolution atlases. All the examples I find leave the actual runtime implementation a total guessing game assuming you don't know NGUI as well as the developer that wrote it.
A real example that actually works on different devices would be very helpful assuming it doesn't leave out support for autorotation.
11
NGUI 3 Support / Re: NGUI 3.0 "Notify" inspector field doesn't list extension methods.
« on: October 01, 2013, 12:17:25 PM »
Really appreciate you taking the time to reply here. I tried making them not static but it seems C# can't make extension methods without them being static. Maybe this is just kind of a thing reflection doesn't work with?
Anywho, I actually want functionality like that of Visual Actions I linked above a lot more than the extension methods. Especially since right now NGUI can't list specific methods for multiple MonoBehaviors of the same type attached to a single GameObject. That(1), being able to edit the order of method calls in the inspector list(2), and maybe an extra component that does nothing but contain a list of method calls fired by a single public method(3), are the 3 things I'm lusting for HARD. XD
Essentially I'm trying to write scripts inside a component! haha (Not really… well sort of XD)
Anywho, I actually want functionality like that of Visual Actions I linked above a lot more than the extension methods. Especially since right now NGUI can't list specific methods for multiple MonoBehaviors of the same type attached to a single GameObject. That(1), being able to edit the order of method calls in the inspector list(2), and maybe an extra component that does nothing but contain a list of method calls fired by a single public method(3), are the 3 things I'm lusting for HARD. XD
Essentially I'm trying to write scripts inside a component! haha (Not really… well sort of XD)
12
NGUI 3 Support / Re: NGUI 3.0 "Notify" inspector field doesn't list extension methods.
« on: September 30, 2013, 07:00:03 PM »
http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx
Those guys. They show up in autocomplete and everything. Great way to add functionality to other people's classes while keeping it encapsulated. Otherwise you're changing their classes and your changes have to be merged when they update and stuff, etc.
Those guys. They show up in autocomplete and everything. Great way to add functionality to other people's classes while keeping it encapsulated. Otherwise you're changing their classes and your changes have to be merged when they update and stuff, etc.
13
NGUI 3 Support / NGUI 3.0 "Notify" inspector field doesn't list extension methods.
« on: September 30, 2013, 01:02:52 PM »
I absolutely LOVE NGUI's new abilities to reveal methods to call in the inspector from various components! It's changed my life! But I just noticed it can't seem to show extension methods. I use those to add things like Pause() or Stop() functions to UITweener for instance. Be great to get those working. THANKS FOR THE AWESOME WORK!
Edit: ACTUALLY, if NGUI could list every method on everything attached to a given GameObject as seen here in the asset "Visual Actions" https://vimeo.com/73517544 That would be PERFECTION! I often need to do things like disable this thing, or enable that thing, that right now I'm finding I'm making little generic scripts just to expose those simple properties. If they were all exposed in the inspector, like Visual Actions makes them, then I would be TOTALLY SETUP!
Edit: ACTUALLY, if NGUI could list every method on everything attached to a given GameObject as seen here in the asset "Visual Actions" https://vimeo.com/73517544 That would be PERFECTION! I often need to do things like disable this thing, or enable that thing, that right now I'm finding I'm making little generic scripts just to expose those simple properties. If they were all exposed in the inspector, like Visual Actions makes them, then I would be TOTALLY SETUP!
14
NGUI 3 Support / Scale panel proportionally such that there is always at least a given border
« on: December 16, 2012, 11:34:51 AM »
I'm having a heck of a time finding a way to get my simple panel containing a column of buttons to scale down as the viewport shrinks so that it doesn't get clipped off the screen. Ideally, I would love a way to set a given amount of border so, if the viewport shrinks enough to begin clipping the border, the panel starts shrinking proportionally to keep that border there.
Anyone know the magic way to get NGUI doing this?
Anyone know the magic way to get NGUI doing this?
15
NGUI 3 Support / Re: UIAnchor for relative positioned widgets in a 3D UI
« on: October 10, 2012, 07:17:19 PM »
I figured out what I was doing wrong. I had anchors as children of panels. This appears to not be how they're intended to be used. Once I started animating my widgets differently to make them move together without keeping them in a single panel it all started to work. I've got 3D UI AND relative positioning! Yay!
Pages: [1] 2