Unity3D——使用UGUI为角色添加名字和血条 - 简书
Unity3D——使用UGUI为角色添加名字和血条
学习Unity3D有一段时间了，庞大的U3D系统可能只学了一些皮毛。最近做东西时又要为怪物制作血条，但一时间竟然忘记了该怎么弄，于是翻翻以前的项目，同时在这里记下来，作为学习参考。
附注1：这是以前刚开始作为学习笔记的文章，但是这里用的添加无数个Canvas的方法显然不太合适，所以大家看看就好了。
附注2: 因为怕误导，所以写上另外一种方法出来，通过坐标转换来实现。——现在的——通过世界坐标与屏幕坐标转换来实现，其实很简单，直接贴代码（阿蠢：你终于发现以前有多傻）
血条跟随代码
——以前的——
在这里我使用的是之前学习的时候自己做的一个官方案例《噩梦射手》的加强版本作为参考素材，而UGUI是unity4.6及以上版本才有的功能。那么，话不多说（阿蠢：=_=你已经说了很多了...）
首先，我们打开Unity3D，在自己的项目中创建一个角色对象，可以用cube之类的代替。这里我放置了3个怪物对象以及1个主角对象（阿蠢：没图说个%&*￥￥@），好吧，上图。
那么，接下来，就是给每个角色添加一个Canvas组件，选中角色对象，右键—UI—Canvas，让Canvas作为角色子物体，此时，你应该看到一个充满游戏界面的Canvas，太大了……(阿蠢：啪！这特么不是废话么！）别急别急，马上解决。我们选中Canvas，将Canvas中的Canvas组件的Render Mode设为World Space，再将其Transform属性的Width和height分别设置为20，10（阿蠢：凭什么听你的，我的属性值我自己调!）经过调整，这时候应该就好多了吧。不过记得也要调整Canvas的位置。
关于Canvas呢，是我们在创建UGUI对象的时候，必须有的一个东西，如同画画，除了画笔，也要有画布才能在上面作画，同时我们创建UGUI对象的时候，也会生成一个EventSystem对象，伴随Canvas的一起出现，要多了解的话，哼哼，去百度吧（阿蠢：不知道就是不知道，没事你装什么装-_=!）
那么，现在，就是开始正式的创建血条了。我们再Canvas下面创建一个Slider对象，右键-UI-Slider，这个没忘吧（阿蠢：你当所有人都白痴嘛！！）那么，现在是不是又有一个硕大的Slider呢？老样子，选中Slider，调整Slider的Scale大小，X：0.02，Y：0.01，同时调整Slider的位置以适应角色对象。（阿蠢：我说了我自己的属性值我要自己调！）这里，我们注意到Slider下面还有几个子物体，这里我们先去掉HandleSlideArea，这里暂时不需要。然后，BackGround是我们Slider的背景，可以控制我们的血条的背景色，FillArea是我们血条的覆盖色，在这个对象下面还有一个Fill对象，该对象有个Image组件，修改Imgae的Color就可以控制血条的覆盖色了，这里我们可以选择自己的项目所适应的颜色来选择不同的颜色。然后，我们回到Slider组件，我们再Inspector面板中找到Value属性（阿蠢：你该上图了，都说了几百字了）
血条Slider属性面板
这里，我们看到有个Directon来控制血条的方向，Min Value表示最小值，Max Value表示最大值，我们先如图设置为100，此时Value的滑块跑到最左边去了，那么我们这里滑动滑块，就可以调整当前的血量值，来看看有没有效果？
注意，我们这里如果添加了能移动的脚本的话，会发现，当角色对象，旋转的时候，我们的血条居然也跟着转了！（阿蠢：我被你骗了，故事不是这样的！）因为Canvas是作为对象的子物体，它的位置是基于父节点的变化而变化，那么这里，我们给Canvas添加一个脚本，就叫做EnemyUiHP吧（阿蠢：我偏不，你个骗子！）。要写的内容也不多
让血条朝向摄像机
我们再Update函数里面添加了这样一句话，是为了让整个Canvas一直面朝着我们的摄像机，这样无论角色再怎么旋转，我们从摄像机的角度看，面向我们的（脚本中的using UnityEngine.UI是在需要再代码中使用UI对象的时候必须要的一个引用，这里多余了）。试试看吧（阿蠢：万一又不对了呢？）。
当然，这里的血条还不完全算是血条，因为没有挨打，没有受伤，不会变化，怎么当一个合格的血条君呢？那么，在这里做一个简单的控制血条的方法，当我们的角色在收到伤害的时候，血量要减少，这是，我们可以添加这样几句代码
这里定义了hpUI对象为Slider组件，currentHealth为当前血量，我们在脚本初始化对象时，如再Start()或者Awake()函数中设置血量的初始值，可以先定义一个最大血量值：public float maxHealth=100,
currentHealth=maxH以及hpUi.maxValue=maxHealth;这样使得血量的最大值就等于我们在脚本中的设置的最大值，之后修改也方便。而如上图在自己定义的受伤的函数中写入hpUI.value=currentHealth。这样当我们的当前血量减少的时候，血条的值也在跟着变化。注意，这里我们使用的hpUI对象是Slider对象，也就是UI对象，这里必须在脚本前引用上面说到的using UnityEngine.UI，否则报错（阿蠢：简直可怕!）
以上就是我们写使用UGUI编写血条的方法了。虽然废话很多，但是为了清晰且方便刚学的小伙伴理解，就见谅了（阿蠢：行行行，原谅你了。）那么这里就给大家看看我自己做的最终效果版本，同样的方法给角色添加了名字（良辰、美景、奈何天）,以及同样使用UGUI制作的小地图等。那么，1,2,3——
有不对的地方 or 有问题 or 有经验 or 有建议的可以多多交流~（阿蠢：别逗了，你这么懒，还会有力气和别人交流？）
Learning Unity。阅读(24725)
Unity终于在即将到来的4.6版本内集成了所见即所得的UI解决方案。事实上从近几个版本开始，Unity就在为这套系统做技术扩展，以保证最终能实现较理想的UI系统。本文试图通过初步的介绍和试用，让读者对这套系统有大体的了解，以便更进一步评估这套UI系统好不好用，适合用在什么项目。为了避免坑挖太深，更进一步的试用和评估我将在《》中进行论述。为论述方便，下文将这套New UI System简称为uGUI，并且以X-UI指代现有第三方UI插件。
（测试只针对Unity 4.6.0 beta 10，正式版可能会有所出入。目前Unity没提供文档，本人半桶水，欢迎群众在微博或Issues里吐槽！）
二、Rect Transform
Rect Transform继承自Transform，是uGUI相比X-UI最显著的区别[]。当你为Empty GameObject加入一个UI Component时，Transform会自动转换为Rect Transform。Rect Transform尽量整合了X-UI常见的anchor(相对父物体的锚点),&pivot(中点),&stretch(拉伸)等属性。值得一提的是，这里的anchor是Rect而非Vector2，因为它不仅用于偏移，而且用于缩放。点击Rect Transform上的准心图标，还能在弹出的Anchor Presets面板中对其进行快速设置。
这个面板还是不够直观，我们可以把它看成一张表，上面四个图标用于设置列，左边四个图标用于设置行，也可以直接点击里面的16个图标同时设置行和列。强大的地方是，按住shift时能同时设置pivot，这时能发现控件虽然不动但position已经在改变。如果按住alt，则设置anchor的同时设置position。如果shift和alt同时按住，那么你就能同时设置anchor, pivot和position。这个操作方式比起X-UI，真的高明很多，对多分辨率适配很有帮助。
除此之外，Rect Transform还提供了Blueprint和Lock Rect选项，前者用于对旋转过的元素进行定位，后者据说明是能在设置anchor时保持位置不变，暂时没搞明白。
uGUI可以直接在Hierarchy面板中上下拖拽来对渲染进行排序(支持程序控制)，越上面的UI会越先被渲染，相比X-UI的global depth排序，这样的拖拽设计很讨好用户。同时在结构上则和ex2D采用的local depth类似，这样GO只和同级其它GO进行排序，开发组件会很方便。需要注意的是，这里排序只是相对UI而言，其它3D物体还是按原先的次序渲染，并且UI总是渲染在3D物体上面。这就导致你不能像用ex2D那样直接将粒子系统插入到两个UI之间。
这种无需填写depth值的排序方式，容易导致没有手工做sprite packing的free版用户遇到draw call增加。因为所有物体的depth都是自动设置的，Unity保证了每个物体的depth都是唯一的。这时假设你有一个格子控件，每个控件用到了两个Sprite，但你并没有把Sprite都拼到同一张贴图上。于是你每复制一个新的格子出来，draw call就会增加2个，因为Unity会以格子为单位依次绘制。pro用户由于有sprite packing机制，不用担心这个问题。（这种情况在ex2D里，是以默认提供"unordered"的渲染方式来解决的，这也是NGUI的默认做法。在这种情况下ex2D会优先以相同depth的相同Sprite为单位绘制，因此不论有多少个格子，draw call都是2个。除非你就是希望以格子为单位进行渲染[]，那么你可以在ex2D里设置渲染方式为"ordered"，或者在NGUI里给每个格子设置不同的depth。
uGUI自带了以上控件，其中Image用于显示Sprite，Raw Image用于显示Texture，Image Mask和Rect Mask用于clipping。所有控件都是MonoBehaviour，可以直接从Inspector里拖到其它GameObject上。
uGUI用Image控件显示图片，图片就是一个Sprite，这意味着Pro用户不用再制作atlas了，相比X-UI是个大进步，Free用户一样可以手动做Packing。Image提供了Simple,&Sliced,&Tiled,&Filled四种效果，和X-UI保持一致。
4.2 Button
uGUI里，Button控件由两个GameObject组成，一个包含Image, Button等Component，一个包含Text等Component。这样设计很组件化，唯一的问题是当用户想修改Button时，容易不小心选中Label或其它实体。
Button Component主要执行Transition和事件两个操作。
Transition可选择改变颜色、更换贴图或自定义动画，使用起来简单方便，也能利用动画定义更丰富的表现。我会再写一篇文章演示Button的Transition。
事件也是所见即所得的，在OnClick里面可以添加多个命令，命令可以选择对应的目标、操作和参数。用法简单，有需要也可以换程序控制。
目标可以是任意Object，例如其它GameObject或者Project里的Asset
操作可以是需要设置的参数或调用的方法
参数分成Dynamic和Static，Dynamic能将控件的参数单向绑定到目标参数，Static则将目标参数设置成预设值。按钮没有Dynamic参数，Toggle, Slider等控件才有。
5.1 Event Trigger
uGUI控件往往只提供一个自带事件，要响应更多基本事件的话，需要添加Event Trigger组件。Event Trigger包含以下事件：
PointerEnter, PointerExit, PointerDown, PointerUp, PointerClick
Move, Drag, Drop, Scroll
KeyDown, KeyUp, Select, Deselect
可以在Event Trigger中Add多个事件，每个事件都可以添加多个命令，用法和控件自带事件一致。
5.2 Graphic Raycaster
每个Canvas都有一个Graphic Raycaster，用于获取用户选中的uGUI控件。多个Canvas之间通过设置Graphic Raycaster的priority来设置事件响应的先后次序。当Canvas采用World Space或Camera Space时，Graphic Raycaster的Block选项可以用来设置遮挡目标。
5.3 Event System
创建uGUI控件后，Unity会同时创建一个[]叫EventSystem的GameObject，用于控制各类事件。可以看到Unity自带了两个Input Module，一个用于响应标准输入，一个用于响应触摸操作。Input Module封装了对Input模块的调用，根据用户操作触发各Event Trigger。理论上我们可以编写自己的Input Module，用来封装各种外部设备的输入，只要加入Event System所在的GameObject就行。
Event System组件则统一管理多个Input Module和各种Raycaster。它每一帧调用多个Input Module处理用户操作，也负责调用多个Raycaster用于获取用户点击的uGUI控件以及2D和3D物体。
2D渲染分两大类，一类是单纯的Sprite绘制，用于渲染场景、角色、粒子等，另一类是UI绘制。Unity将这两类需求划分成了SpriteRenderer和uGUI两部分，前者由Transform&+&SpriteRenderer实现，后者由Rect Transform&+&CanvasRenderer&+&UI控件&+&Canvas[]实现，这样的两套相对独立的机制比起X-UI的UI控件继承自SpriteRenderer更为合理。因为在2D游戏里SpriteRenderer只需要关心最基本的面片渲染，注重效率，而UI注重各类变换、对齐、操作、动画，还常常需要Resize VBO。如果SpriteRenderer在设计上需要兼顾UI，就会像X-UI那样设计得太过复杂，在用户体验和性能上都很不好。
这里我们探讨一下uGUI的渲染机制，当我们渲染多个使用相同Sprite的控件时，并没发生dynamic batching，但是drawcall也没有上升。这就说明Unity在内部使用了专门的一套batching机制，把多个控件的VBO事先合并成了一个。也就是说CanvasRenderer不负责实际渲染，而是由Canvas批量渲染多个CanvasRenderer，这和部分X-UI采用的做法一致。这样单独batch的设计有可能使得性能比SpriteRenderer好，也可能导致性能更差。性能会更好的情况在ex2D里已经证实了，主要原因是这样能更好的平衡CPU和GPU负载，并且能做到更优化的batching算法。性能更差的情况，在去年旧版的NGUI测试时也遇到了，根本原因还是优化不到位导致的（不是贬低，不同工具的取舍和面向市场都不同）。而Unity的 SpriteRenderer在手机上的渲染跑分是和ex2D持平的，CanvasRenderer又比SpriteRenderer快[]，因此uGUI的性能不用担心。由于目前没有Mac版本，我会在正式版发布后进行一次手机跑分测试。
uGUI功能完善，操作简洁，很接地气。可以说uGUI是相对X-UI的全面升级，整体架构更为严谨，实现更为清晰。依托4.5的Module Manager，uGUI以Package的形式提供，也能获得快速的升级[]。作为ex2D v2.0开发者之一，我很看好它将来的发展，uGUI将在大多数场合取代X-UI。
初步感受：
RectTransform
Event/单向数据绑定
直接在Hierarchy中排序
Pro用户可用Sprite的动态拼图，无需手工拼图
7.3 小遗憾
Anchor Presets面板还不够直观。
用户想修改Button时，很容易修改到Label。
当Hierarchy面板内的目标节点展开子节点后，无法将其它节点直接拖动到目标的正下方。
7.4 小问题
Input组件对方向键的支持有问题。
Game View dock到主窗口后，top定位有误，把toolbar的高度也算进去了。
我们在其它平台上开发类 Entity-Component框架时，讨论过Unity为什么不在底层对transform做特殊处理，以避免插件作者手工缓存transform来优化query transform引起的开销，甚至是将transform直接整合进GameObject。原因是现在的transform是3D的，将来完全可能推出 2D Transform。所以Unity在之前的版本里一直保留着transform的独立性。
我不能完全肯定一定是Canvas，但通过Canvas和CanvasRenderer的接口来看，这个可能性很大。
基于更好的平衡CPU和GPU负载 + 更优化的batching算法，以Unity的实力CanvasRenderer超越SpriteRenderer问题不大。而且如果性能不会提升，uGUI只要像2D Toolkit那样给每个控件直接添加MeshRenderer，也就是说uGUI直接用已有的SpriteRenderer就好，不太可能加入新的CanvasRenderer性能反而更慢。
Unity允许多个Event System同时存在，但同一时刻只有一个能够生效。
uGUI的控件、Event等模块以包的形式提供，位于程序目录下的%UNITY%\Editor\Data\UnityExtensions\Unity\GUISystem\4.6.0，Unity 提供了两个运行时版本的DLL，分别用于创作和发布。区别主要是发布版不含一些Editor中才用得到的代码。由于DLL没办法通过预编译符号来进行条件编译，因此Unity使用这种方式进行权衡，用户发布时无需手工切换DLL版本，满足了闭源，又兼顾了执行效率。这样就甩开了第三方插件几条街，很多插件在这个问题上不是牺牲性能就是无奈开源。
有时还是会需要以格子为单位渲染，例如当格子之间需要重合，这种需求在UI里不常见。
阅读排行榜写完《》后，我模仿手机上的UI分别用uGui和NGUI做了一个仅用作演示的ToggleSlider，我认为这个小小的控件已能体现自定义控件的开发过程。由于手头上没有mac版，暂时未能真机测试，PC上的效果如下：
二、制作过程
完整工程托管于，分为和两个project。考虑到版权问题，工程里不含NGUI，同学们需自行将NGUI导进工程。NGUI需要Unity 4.5，uGui需要Unity 4.6。
三、功能点
滑块可以拖动，从一边拖到另一边将改变控件值。
用户停止操作时，滑块如果居中，会自动滑向最近的一边。
点击滑块或整个控件，控件值将被改变，滑块自动滑向另一边。
控件值被其它脚本修改时，滑块自动滑向另一边。
滑块移动的过程中，如果值发生变化，滑块会以当前位置为起点滑回去。
下面以uGui为例简述制作方法，NGUI的方法也差不多，两者的区别可参考下文[]。
四、Hierarchy
上图是用uGui制作好的层级结构。其中，
Canvas负责渲染UI。
Padding没什么用，只是画了一个边框。
Toggle Slider是控件的父物体。
BackgroundAndMask使用ImageMask组件作为SymbolOff的遮罩，同时渲染灰色底图。
SymbolOff是灰色的twitter小鸟，坐标受动画控制。
Background_On使用Image组件渲染蓝色高亮底图，Color.alpha受动画控制。
BackgroundMaskOnly使用ImageMask组件作为SymbolOn的遮罩，并不渲染。
SymbolOn是蓝色的twitter小鸟，坐标受动画控制。（不用Background_On作遮罩是因为蓝色底图的边缘是半透明的。）
Handle是正方形滑块，坐标只受动画控制。
Current Value是下面那个可选框，用于测试Toggle Slider。
EventSystem可参考上篇文章。
五、Toggle Slider GO
Toggle Slider对象包含的Toggle Slider组件是唯一一个直接和控件有关的脚本。代码可在查阅，编写起来很简单。
六、Animation
所有效果都使用Animation组件实现，全部用动画是为了偷懒，毕竟效果怎么实现都可以，这里仅作演示。动画包含四条曲线，分别用于控制两只twitter小鸟、蓝色背景透明度和滑块左右移动。这里简单提几个要点。
动画的反向播放只需要将AnimationState.speed设为-1。
拖拽滑块时，动画暂停，根据鼠标位移逐帧设置动画时间，然后Sample动画。拖拽停止时恢复动画。
在动画里改变透明度时，Image组件不会自动更新，需要添加一个组件，自己触发Image.color的setter。
动画设为ClampForever，因为Once无法在AnimationState中保留最后一帧的状态。
事件使用两个Event Trigger组件进行响应。一个在Toggle Slider对象里，负责响应OnPointerUp，实现当点击控件时，调用ToggleSlider.Toggle()。另一个在Handle对象里 (如图)，负责响应Drag事件，实现当拖动时调用ToggleSlider.OnDrag()。
在此遇到了一个蛋疼的问题，Event Trigger的Drop事件在这里无效，又没有单独的DragEnd事件，因此只好在Handle上增加OnPointerUp事件来监听拖动是否结束。如此一来，Handle的OnPointerUp就会把上层控件的OnPointerUp事件拦截掉&&我希望Unity能提供类似冒泡的机制，这样一来我就能在Handle上添加一个脚本，只对拖拽结束进行响应，如果是单击事件就冒泡到上层控件进行处理。
最终我的做法是，Handle的OnPointerUp事件也由ToggleSlider.OnPointerUp()响应，OnPointerUp内部通过dragging标记来判断是拖动结束还是单击。
Event Trigger没有冒泡机制，子控件如果不处理事件，没办法抛给父控件处理。
ImageMask没能选择alpha threshold。
九、存在的Bug
这段时间的测试遇到过几个问题：
经常警告"Material uGUI/Stencil Mask doesn't have stencil ... SendWillRenderCanvases()"。有时会导致Image无法显示，要换过一次Sprite之后才正常。
两个Hierarchy内平级并且相邻的ImageMask，都选中DrawImage，结果上面一个会挡住下面一个。需要在两个中间插入一包含CanvasRenderer的GO才行，GO可以deactivated。
当我制作NGUI版本时，从uGui复制了一份出来再做修改。做到一半时我发现Hierarchy多了一个不含子物体的副本，当我选中控件时副本会同时被选中。于是我重启Unity，发现Unity已经死锁无法关闭，强制结束后项目损坏，只要一打开就crash，手动删除scene后才恢复正常。估计是我在继承树上混用NGUI/uGui，或者uGui未剔除干净引起的，已向官方反馈。
十、和NGUI对比
作为对比，我也用NGUI的测试版(3.6.4b)做了一样的demo，花了不少时间。uGui的事件问题也在NGUI里遇到了，甚至更严重，此外还有其它问题。
NGUI的padding设置挺繁琐的，uGui只要Rect Transform点下stretch，Left/Top/Right/Bottom全写20就行。
添加padding时，我试着创建一个UIWidget，然后设置Anchors为Unified，然后依次设置Left/Top/Right/Bottom为Target's Left/Top/Right/Bottom，然后数值填入20/-20/20/-20才行。
NGUI添加Toggle有点复杂，uGui只要Hierarchy里Create一个就完事了。
创建调试用的Current Value时，找不到NGUI的Toggle组件，后来输入名称才找到，但还是不太会用。后来想到Examples里有toggle的prefab可以用，拖进Scene后对比了下发现NGUI的实现方式比uGui复杂了些，难以手工创建出来。看来Project里要把NGUI这些常见库都备好才行。
NGUI设置Anchor有点失败
将Toggle的prefab实例化到scene里后，设置了很久都没能让Toggle自动居中。难道这个Toggle的尺寸如果是动态的，NGUI就没办法自动居中？或许是我对NGUI还不是很了解，最终我只能根据Toggle宽度算出坐标偏移。
NGUI没有Image Mask
所以这个版本没能加入那两个twitter的logo。这个怪不了NGUI，因为Unity的free版不提供访问stencil buffer的功能，因此第三方UI插件没办法实现比较好的clipping机制。
NGUI的UIEventTrigger无法获得事件参数
UIEventTrigger和uGui的EventTrigger类似，能够触发远程方法。但是NGUI不能传入动态事件参数，虽然能用 UIEventTrigger.current获得当前事件，可UIEventTrigger对象其实没定义任何参数。要获得参数，只能自己写一个带有 OnDrag的组件，附加到GameObject上，或者使用UIEventListener，总之就不支持可视化编辑，只能用代码动态绑定事件。
NGUI的UIEventListener无法响应停止拖动事件
为了解决前一个问题，我使用了UIEventListener来获得拖动参数。然而当我想响应停止拖动事件时，我发现还是要用回UIEventTrigger才行。如果用户不希望混用这两个脚本，那么只能自己写一个脚本。
十一、小结
uGui功能和用户体验方面都做的不错，是我看到过最贴近Unity风格的UI系统。稳定性方面有小问题，不过作为测试版可以理解，已经超过了我的预期(之前以为会和4.0的刚推出Mecanim一样bug一堆)。
性能方面，两个工程我都实现了相同的PackedBenchMark场景，里面各包含了30个ToggleSlider，为了公平uGUI版本去掉了所有ImageMask，两边实测drawcall一致。从帧率上看在编辑器下NGUI性能优于uGUI大约20%！估计是因为NGUI在最近几个版本中完善了batching机制，而uGUI并没有采用前一篇文章所说的"更优的"batch算法，而是把batching粗暴的交给了显卡驱动完成。如果有pro版的话使用profiler查看一下两边的CPU/GPU占用就能知道答案。
本文作者： @
本文转载自
阅读(...) 评论()这里来讲解下UGUI 滑动条(Slider)的用法
控件下面有三个游戏对象
Background --&背景
Fill Area --& 前景区域
Handle Slide Area --& 滑动条
Slider的属性
其他几个设置和其他控件都差不多，这里来讲解几个特有的属性。
Direction --&方向
Whole Numbers --&控制整数输入
然后来看下脚本控制。这里的方法调用和其他的不用，方法里面有浮点参数
using UnityE
using System.C
public class SilderTest : MonoBehaviour {
// Use this for initialization
void Start () {
// Update is called once per frame
void Update () {
public void SliderTest(float even) {
Debug.LogError("您的血量=" +even );
然后通过绑定脚本，能够在改变滑动条的值的时候，调用方法。
阅读(...) 评论()Unity3d&UGUI&Slider变色
using UnityE
using System.C
using UnityEngine.UI;
public class SliderColor : MonoBehaviour {
& & public Color[] colors =
new Color[] { Color.red, Color.yellow, Color.green };
& & Slider mS
& & // Use this for
initialization
& & void Start()
& mSlider = GetComponent();
& mSlider.fillRect.transform.GetComponent().color
& Update();
& & void Update()
& float val = mSlider.
& val *= (colors.Length - 1);
& int startIndex = Mathf.FloorToInt(val);
& Color c = colors[0];
& if (startIndex &= 0)
(startIndex + 1 & colors.Length)
& & float factor = (val -
startIndex);
Color.Lerp(colors[startIndex], colors[startIndex + 1],
& & & else if
(startIndex & colors.Length)
& & c = colors[startIndex];
& & & else c =
colors[colors.Length - 1];
mSlider.fillRect.transform.GetComponent().color.a;
& mSlider.fillRect.transform.GetComponent().color
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}