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.


Messages - n8

Pages: [1] 2
1
NGUI 3 Support / Unable to change UISprite at runtime
« on: August 10, 2014, 11:31:12 PM »
I am attempting to change a UISprite to a new sprite from within the same atlas using this method:

sprite.spriteName = "newSpriteName";

When I run this, the sprite name changes in the inspector, but the actual sprite being rendered goes blank.  I am using the latest version of NGUI at the time of this writing (3.6.9). I have made sure that the sprite is set to use the "Simple" display type.

Thanks in advance for any help.

2
NGUI 3 Support / Re: Tutorial questions from a new user.
« on: May 01, 2013, 10:43:31 AM »
Both questions are fairly simple to answer, but a bit difficult to discover on your own.

1)   I am working on going through the tutorials and I’m right at the start. Every time I click the “Make Pixel-Perfect” button it resizes my sprites to be much smaller then I have scaled them to be. Always the same size but much smaller then I want. Why is this happening?

A sprite is "Pixel Perfect" when it is scaled to the same size that it was originally created at in your image editor.  For instance if you create a an image that is 64X64 pixels in photoshop, then import->add to Atlas->create sprite, then scale the sprite to 128X150, your image is being scaled above it's original intended size and could become blurry or pixelated.  Hitting "Make Pixel Perfect" will bring it back down to 64X64 where the image is not being stretched in any way, restoring it to a clean non pixelated state.  one way of getting around the pixelation is to setup the sprite to be either tiled, or sliced which leads me into your next question:

2)   In the tutorial they make a sprite that tiles. I see how to make a sprite, I don’t see tiling sprite as an option in the widget tool. What am I missing?

to setup a sprite so that it can tiled is very simple just click on the created sprite and you should see a selection box under the color selection that says "Sprite Type". Just select tiled and then you can stretch out your sprite as much as you want and the sprite will tile to fill the space.

you follow the same instructions above to set the sprite as sliced, however there is another step you must take to see the full effect of this type of sprite.
First find the atlas prefab in your project (you can do this by selecting the atlas in the widget wizard window, Unity will highlight the corresponding prefab your project).  Select the atlas prefab and you will see a UI in the inspector for modifying some of the properties of the atlas.

Select the sprite that you are wanting to make sliced, then adjust the "Border" fields to your liking.  You can watch where the borders are in the sprite preview below.  You will want to move your borders in to the point where your sprite's outer edge is outside of the border, this mode will cause the part of the sprite that is "inside" of all the borders to be stretched, while keeping the part of the sprite outside of the borders to be pixel perfect

I hope this helps you get off the ground




3
NGUI 3 Support / Re: Atlas Switching script
« on: December 28, 2012, 12:46:16 PM »
isn't what the "UV rectangle" is for on the UITexture script?  make the texture POT and then put the background in that filing whatever space it needs, then set the "UV rectangle to the size of your useable image.  I guess either way you are going to have some wasted space it seems

4
NGUI 3 Support / Re: Atlas Switching script
« on: December 28, 2012, 11:50:22 AM »
not to criticize your design, but 4 font and 3 atlas references seems a bit high.  Are those references just for different resolutions or are they actually being used in your UI?  if they are just the different resolutions, then you should only have one atlas reference and have all of your ui components using that one, and one font reference where all fonts are using that one.  Then you should only have to clear out those two reference objects before building. 

If you have 4 fonts and 3 separate atlases in your UI, then I would seriously recommend redesigning your UI to stream line down to one of each.  each atlas requires a draw call and extra memory usage, so I would do my best to minimize the need for extra atlases and fonts, especially if you are wanting to run well on older devices (3gs and lower, most android phones).

As far as automation, I am not intimately familiar with tweaking Unity's build process.  My first thought would be to write a standard Editor script that would let you just push a button and clear those references before firing off a build.  I am not really sure how to make that whole process completely automated.

5
NGUI 3 Support / Re: Atlas Switching script
« on: December 28, 2012, 10:52:04 AM »
Nicki is correct, you should clear out the original atlas in the editor before building to be certain that you are not loading then reloading an atlas into memory.

6
NGUI 3 Support / Re: NGUI Virtual Joystick
« on: December 12, 2012, 03:34:13 PM »
unfortunately, I don't see the problem in your video.  The video doesn't show where your physical touch so you can't really tell how the joystick is reacting to the touch.  Try adding a debug sprite to the screen that follows the physical touch (make this separate from the joystick script), so that we can see the true behavior.

The only thing I could think of off the top of my head is to make sure that the cameras are setup correctly.  The joystick script uses a raycast from the "currentCamera", make sure that camera is the one you are expecting and that it is setup how it should be.

7
NGUI 3 Support / Re: How to pass arguments along with UIButtonMessage
« on: December 12, 2012, 12:44:03 PM »
Aren,
I understand why you are encouraging a custom script. I can also agree that there could be a lot more argument functionality built into a custom script.  However, the UIButtonMessage script is already very well adapted to handling clicks/touches in the NGUI environment, and any custom script would prob just be an exact duplicate with the parameter option added.

I guess I just don't understand why the parameter option is really being used already by UIButtonMessage.  Seems like there are plenty of use cases for needing to pass a single parameter into a function on a button press.

To be clear, I think what you have done is great, just some clarification on the thought process would help.

8
NGUI 3 Support / How to pass arguments along with UIButtonMessage
« on: December 12, 2012, 12:17:01 PM »
I have been running into several scenarios where I am needing to pass an argument along to a function when a button is pressed.  I have been using crazy workarounds for some time now as I didn't really want to mess with the underlying core of NGUI scripts.  Finally ran into a case where I needed to generate buttons at runtime that then needed the ability to pass specific GameObjects back to another object to be instantiated when that button was hit.   This solution seems to be working great in this context.

(note in order to preserve NGUI's private code I am only posting the changes necessary to make this work)

around line 26 add this:
public Object parameter = null;

now find all instances of the call "SendMessage".  There should only be 2 and located at the very bottom of the script in the "send" function (at time of writing).

replace the call of "SendMessage"
From:
SendMessage(functionName, gameObject, SendMessageOptions.DontRequireReceiver);
To:
SendMessage(functionName, parameter, SendMessageOptions.DontRequireReceiver);

Right now the "SendMessage" only supports one parameter (Unity thing), but there are some roundabout workarounds for getting more than one to pass.

If there was a specific reason that the generic "gameObject" was being passed instead of parameters, please let me know.  So far this seems to be working for my needs.

Please let me know if there is any confusion or explanation needed

9
NGUI 3 Support / Re: Atlas Switching script
« on: October 31, 2012, 12:20:54 AM »
Happily, this works 100% here:
  1. ReplacementAtlas = Resources.Load("GUI/SHD/" + SHDAtlasName, typeof(UIAtlas)) as UIAtlas;

And should use fewer resources too boot! Woot! :)

nice! when I was writing my script I was attempting to make it as easy as possible to use in most systems.  I am surprised it did not work as is in yours.  I like your solution to target the UIAtlas specifically though.

10
NGUI 3 Support / Re: Atlas Switching script
« on: August 08, 2012, 04:19:07 PM »
this script should work just fine on android.  You will just need to figure out what resolutions you want to use to trigger the switch.  For instance the nexus s has a resolution of 480 x 800.  I use that as the "SD" resolution. the Galaxy tab 10.1 (roughly equivalent to the ipad in resolution) is 1280x800, so that could be your cut off for "HD" resolutions.  You could also go the route of treating most phones as "SD", most 7" tablets as "HD" and then 10" tablets as "SHD".  it is really all up to you.

11
NGUI 3 Support / Compare sprites in different Atlases
« on: August 01, 2012, 01:34:23 PM »
I am building a UI with the ability to switch between 3 different atlases (sd, hd, shd). while working in the editor I am defaulting to the HD atlas to make elements and then have a script to switch the atlas at runtime.  Problem is that as I am working, I became lazy and added sprites that I needed to the HD atlas and forgot to add them to the other two ( or added them to two of the atlases and forgot one).

Is there a way to evaluate, side by side, the different atlases to ensure they have the same list of sprites added to them?

thanks in advance for any help or feedback.

12
NGUI 3 Support / Re: My NGUI suggestions.
« on: June 28, 2012, 06:57:15 PM »
+1 for the sliced tiled sprite.  I was trying to figure out how to build my sprites to do this, but never thought to use more than one. I would like the ease of ngui applied here.

13
NGUI 3 Support / Inventory: Store implementation
« on: June 26, 2012, 04:43:42 PM »
Hello,

I have started down the path of using the inventory system included with NGUI (Orc example).  I have started tweaking it a bit to tailor it to my setup and have a very basic implantation working.  My end goal is to create a store that is populated with these inventory items.  When an item has been purchased it will marked as so ( I will need to add a data point to inv base item), and then that item will show up in player's inventory at a later time.  I also have several playable vehicles that will be having these items applied to. My goal is to have one global "backpack" that contains all of the items a player has purchased, and then have slots on each of the vehicles, so that the player can assign the item to that vehicle.  I am sure that this setup is possible, but could someone point me in the right direction? do I need mulitple item databases (one store and one player purchased)? Multiple Item storage (one for player purchased, one for each vehicle)?

Either way I am assuming that I will need to write my own scripts to read from the database and then create the items first in the store window, then in the player's purchased storage area, and then individual vehicle storage?

Thanks in advance for any help or direction!

14
NGUI 3 Support / Re: Proposing UIFill, UIStick and UIHook
« on: June 26, 2012, 11:38:44 AM »
+1 for adding these to NGUI

15
NGUI 3 Support / Re: Atlas Switching script
« on: June 25, 2012, 11:20:19 PM »
Cool stuff. I have some notes. :)

For one of our upcoming games, I used a similar setup but with arrays of atlases and fonts, since I had a few of them.

I also defaulted my reference atlas to the low res so I could work with it in the editor, instead of having to setup while playing. When I do this, I have to switch back to the low res when I end a play (OnDisable or OnDestroy) or the prefab will be marked as changed in version control.

Yeah I was only needing the three atlases, so I didn't bother with setting up arrays.  And yeah I could see setting up to revert back to the first atlas, I find it easier to just not have the script run in the editor.

I'm not sure why you need the script execution order for this, since it should change "nicely" no matter when you change the things. This may just have been a sideeffect in my project, since it had the low res loaded from the beginning.

I guess it could work without doing that. I was just under the impression that it needed to run before ngui loaded

I also just attached mine to the UIRoot so I knew it would always be in the scene, but anywhere will do.

Good idea!

Pages: [1] 2