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.


Topics - JRoch

Pages: [1]
1
This is likely a Unity issue, but I'm wondering if anyone has encountered this and solved it.  My app works great any any window size (windowed or full screen) except when the chosen "screen resolution" (or window size) is one that equals the vertical height of the display.  In this case it is when I pick one of the two resolutions that are *x1200.  (1920x1200 or 1600x1200)  In all other cases the NGUI ui is correctly scaled and pixel perfect.

In the two attachments to this post you can see that at 1920x1200 the UI has become oddly stretched, and the UI elements are slightly larger than they're supposed to be.  In addition, the calculation of screen coordinates goes haywire.  The mini map has logic where the white selection box centers up where ever you click with the mouse.  In the correct version, I have clicked on the center of the mini map and the coordinates are correctly calculated.  In the messed up version I have also clicked on the center of the mini-map, but the calculated coordinates are way off, resulting in the white view indicator being off.  This mis-calculation appears to be relative to the center point of the screen, which means the error gets larger the further away from the center of the screen you get.

In all other resolutions the UI is correct and the calculation of widget offsets for mouse clicks is also perfect.  I'm at a loss to explain why this is happening.  The actual 3D area of the application is *not* incorrect and is properly scaled and has no issues with stretching, pixel blurriness, or incorrect offsets.  The mouse handling in the OnGUI portion of the app is also correct.

Extra info:  Running two monitors side-by-side at 1920x1200.  Win7 x64.  Nivida card with latest drivers.  No other issues at all.

2
NGUI 3 Support / Useful script: global gameobject tracker
« on: October 30, 2012, 11:31:07 AM »
There are likely better ways to do this, but it will suffice for simple situations where you wish to store handles to gameobjects (often UI items) and then be able to get handle references by gameobject name lookup.  At the very least, those of you who are new to coding will find this simple class an example of how to track gameobject handles so that you can interact with them after you've disabled them and can no longer use the Find or FindChild functions to get a reference.

This class script should be attached to any gameobject that you might want to get a reference by name later on.

  1. using UnityEngine;
  2. using System.Collections;
  3.  
  4. public class GlobalGameObjectTracker : MonoBehaviour {
  5.  
  6.     // This class is used to get references to unique objects within the hierarchy by unique name
  7.  
  8.     private static Hashtable _globalGameObjectLookupByNameHashtable = new Hashtable();
  9.  
  10.  
  11.         // Use this for initialization
  12.         void Awake () {
  13.             if (_globalGameObjectLookupByNameHashtable.Contains(this.name))
  14.             {
  15.                 Debug.LogError("Duplicate GameObject named: " + this.name +"\nCannot add item to GlobalGameObjectTracker hashtable.");
  16.                 return;
  17.             }
  18.         _globalGameObjectLookupByNameHashtable.Add(this.name, this.gameObject);
  19.         }
  20.        
  21.     public static GameObject GetGameObjectByName(string gameObjectName)
  22.     {
  23.         if (_globalGameObjectLookupByNameHashtable.Contains(gameObjectName))
  24.         {
  25.             return (GameObject) _globalGameObjectLookupByNameHashtable[gameObjectName];
  26.         }
  27.         Debug.LogError("Could not find GameObject named: " + gameObjectName + "\nCannot find item in GlobalGameObjectTracker hashtable.");
  28.         return null;
  29.     }
  30. }
  31.  

In any other script you can then call GlobalGameObjectTracker.GetGameObjectByName(unique_object_name) to get a gameobject variable handle.

3
NGUI 3 Support / PixelPerfect causing 1-pixel resizes
« on: September 16, 2012, 03:05:16 AM »
I'm fighting with sliced sprite and single sprites that NGUI keeps being a bitch and resizing widgets by one pixel.

For example, I've got a backdrop for text areas that is a 150x25 sliced sprite with correctly specified border.  I want these backdrop boxes to be exactly 25 pixels tall.  However, at runtime NGUI consistently bumps the height to 24 pixels.  If I bump the height to 26 pixels, NGUI doesn't touch it.

I also have a button that uses a sprite that is 15x12 pixels.  NGUI consistently bumps this to 16 pixels wide at runtime.  However, the underlying backdrop that is under the two halves of the button control (it's a plus/minus spinner) is a 15x25 pixel sprite which NGUI doesn't resize... although it does correctly give it a half-pixel offset, which it doesn't do for the overlying button sprites.

What the hell do I have to do here... only work with sprites that are evenly divisible by 2 to avoid flaky math errors in the PixelPerfect logic?

4
NGUI 3 Support / Pixel Perfect Weirdness
« on: July 26, 2012, 09:43:22 PM »
So I'm toying with different ideas for UI themes and, since I'm inspecting the screen closely, am noticing that some of my test menus just aren't doing their pixel perfect magic very well at all. (See attached image.)

Are there any caveats to making pixel perfect work correctly?  I tend to have a structure like this:

UIRoot -> UICamera -> UIAnchor -> OriginObject -> UIPanel ->UIsub-widgets

The "OriginObject" is just an empty GameObject I stick in the structure that has the correct origin for the panel that is a child of it.  This allows me to set the panel's transform position with something like Y = 1000 so that it is not on the screen while I'm working with other elements.  I have a script attached to each UIPanel that set the local position back to 0,0,0 on Awake.

So what I'm seeing is that the left-hand menu isn't pixel perfect (backdrop or icons or text) while the one on the right is.  What could be causing this?  Note that it looks like this both in the Editor and while the app is running.

5
Hello folks,

I have a simple window, with a vertical scroll list defined as the standard UIPanel, UIScrollbar, UIGrid, and sub-items that I add at runtime via NGUITools.AddChild.  The children have UIDragPanelContents attached to the topmost object, which also has the collider attached.

Two behaviors that I'm trying to remedy:

1.  The list populates and builds properly.  However, it starts mid-point (center point) of the scrollable area.  Is there a script method I should be calling to get these items to flow correctly top-down in the panel area rather than have them flow middle-down?  [edit:  the first time you touch the scroll bar with the mouse it properly repositions the content and re-sizes the scrollbar.  I'm sure I'm just missing a simple method call to make this happen at the end of list creations.]

2.  Clipped items (in both hard and soft clipping) are still clickable.  I noticed this because items flowing off the bottom of the window, while invisible, are still "over" the "OK" button... and trying to click the OK button results in selecting a list item if the list extends out of the clipped area and over the button area.  Shouldn't the collider for list items also be disabled as they exit the clipped area?

Pages: [1]