NGUI研究之开发项目的一些使用心得比较细节



不知不觉使用NGI插件已经有一段时间了,感觉NGUI真的是目前Unity3D中最好用的UI插件。但是它也有一些不是BUG的BUG,这些问题可能会让新人摸不着头脑,那么这篇文章将总结一下这段时间用NGUI的一些开发心得,这些也好几个朋友问题我的一些问题,我将这些东西列出来。 上一章我们学习了NGUI研究之自制Scroll
View实现触摸滚动相册效果
不明白的同学可以去看看。

1.对图片的限制

如果是移动平台中iPhone 或Android请保持的你的图片尺寸在小于等于1024 X 1024 ,否则载入的图片将无法显示,绘制图片的地方会是一片黑漆漆的东西,PC平台的话图片最大使用的尺寸是4096X4096 。

注意!这还没完、如下图所示,无论在任何平台中请保持你的图片宽或高的尺寸和下图中的一样。比如 32X32 、32X64 、 128 X 32、 1024 X519、 1024 X1024、 512 X 32 像这样和下图所出现的尺寸数值一样的比例才行。 

举个例子,比如美术给你出了一张960X640的图片,此时你直接放在程序中,NGUI会自动将这张图片拉伸。所以你需要让美术把这张960X640的图片放在1024X1024 尺寸的图中给你,这样图片就不会拉伸了,如下图所示,就好像这样,这张图的尺寸是 1024X1024 但是程序中通过精灵切割的只是 960X640这部分,所以这个图就不会在iPhone或Android中拉伸。

接着是材质,对材质着色器的选择也有一点要求.如下图所示,请选择你的材质着色器为Unlit/Transparent Colored  如果你选择的不是它将会造成你的UI无法显示背景透明的图片喔。

 2.精灵预设或者字体预设

在导航栏中创建用NGUI创建一个新UI后,并且在Project视图中已经创建了精灵预设和字体预设后。然后在Panel(面板)中创建新部件时,如下图所示,点击Atlas 或 Font后如果发现找不到对应的预设。不要紧张其实很简单,只需你将Project视图中的精灵或字体预设先拖拽至Hierarchy视图中,此时在重新点击创建新部件,然后在点击Atlas或Font就会出现你需要的精灵或字体预设。选择完毕再将Hierarchy视图中拖拽的预设删掉即可。 对于任何一个新精灵预设或字体预设都要用一次这样的方法,再次使用就不会出现这个问题。

(补充,引用评论中的一句,鼠标在Project视图中点一下就可以  感谢回复~~)

3.在3D世界之上创建你的UI。

比如3D游戏中界面中选择技能、物品、人物状态等的一些UI。这些UI不会以因主角移动而发生位置的改变,并且永远出现在界面最前面。如下图所示,把你游戏世界中原本的摄像机放在UI Root (2D)下面,并且让所有的UI都是这个Camera的子类,这么做是为了解决摄像机发生移动后所有的UI也能和他保持原本的距离关系,至于其它的3D游戏对象请保持与UI Root (2D) 为同级关系即可。因为需要显示3D物体,请设置你的摄像机Projection为Perspective。

4.Scroll View列表的显示区域

如何修改Scroll View列表的显示区域。这个问题我记得有好几个朋友都问过我,我觉得这个问题是NGUI的一个BUG。 但是我们使用另外一种方式可以很好的解决这个问题,那么和大家说说我的开发心得。

如下图所示,在这里可以修改ScrollView中整体的显示区域,但是请注意这里紧紧是修改它的显示区域,,因为之前设定在ScrollView中的item的位置是不会因为scrollView显示区域的修改而修改。建议修改ScrolleView显示的宽 和高 在这里修改,但是显示的X Y轴坐标就不要在这里改了,因为改了也没用。

如果你要修改Scroll View显示X Y轴坐标的话,如下图所示,直接在Hierarchy视图中选择ScrollView显示的父面板对象,然后在Scene视图中更改这个对象的XYZ坐标即可,这样对应下方所有的ScrollView 的item也会跟着修改。继而达到完美修改NGUI ScrollView的显示区域喔。

最后,这篇文章也没什么代码,不过希望能给一些刚刚入门NGUI的朋友一些帮助。

时间: 2024-10-09 17:52:31

NGUI研究之开发项目的一些使用心得比较细节的相关文章

NGUI研究之开发项目的一些使用心得比較细节

 不知不觉使用NGI插件已经有一段时间了.感觉NGUI真的是眼下Unity3D中最好用的UI插件. 可是它也有一些不是BUG的BUG,这些问题可能会让新人摸不着头脑,那么这篇文章将总结一下这段时间用NGUI的一些开发心得.这些也好几个朋友问题我的一些问题,我将这些东西列出来. 上一章我们学习了p=821" rel="bookmark">NGUI研究之自制Scroll View实现触摸滚动相冊效果不明确的同学能够去看看. 1.对图片的限制 假设是移动平台中iPhone

iOS开发项目篇—41cell的frame的细节处理

iOS开发项目篇—41cell的frame的细节处理 一.简单说明 在首页控制器中使用自定义的UITableViewcell 代码如下: YYHomeTableViewController.m文件 1 // 2 // YYHomeTableViewController.m 3 // 4 5 #import "YYHomeTableViewController.h" 6 #import "YYOneViewController.h" 7 #import "Y

NGUI研究之在Unity中使用贝塞尔曲线

鼎鼎大名的贝塞尔曲线相信大家都耳熟能详.这两天因为工作的原因需要将贝塞尔曲线加在工程中,那么我迅速的研究了一下成果就分享给大家了哦.贝塞尔曲线的原理是由两个点构成的任意角度的曲线,这两个点一个是起点,一个是终点.在这条曲线之上还会有两个可以任意移动的点来控制贝塞尔曲线的角度.如下图所示,点1 和点4 就是起点和终点,点2 和点3 就是控制曲线角度的两个动态点.上一章分享了开发项目的一些使用心得比较细节对新手很有用可以看下. 如下图所示.使用拖动条来让曲线发生旋转,大家会看的更加清晰.目前我们看到

如何在程序开发项目中选择合适的 JavaScript 框架,节省时间和成本的9款极佳的JavaScript框架介绍

从技术上来看,iOS,Android 和 Windows Phone 上的移动应用是使用不同的程序语言开发的,iOS 应用使用 Objective-C,Android 应用使用 Java,而 Windows Phone 应用使用 .NET. .随着 JavaScript,CSS 和 HTML 知识技能的提升,相信你也可以构建一个超赞的移动应用.在这篇博客里,我们将会介绍一些极好的 JavaScript 移动应用程序开发框架. 说到网络开发,就不得不说 JavaScript,这是一款很有前途的程序

为什么程序员的开发项目总是半途而废?

很多程序员的项目常常半途而废.他们有那么多的好点子,但是很多都流于空想.几乎每一个软件开发者都有一个这样的文件夹,里面很多都是些还没完工的项目,而这些程序里有不少在它诞生初期真心是个超棒的点子.和这些人一样,我也有很多好主意,有的甚至就是现在有些企业在用的.比如正决定着在eBay上还是在Amazon上做电子商务获利.做一个以业务为基础的社交网络(水管业.电子行业.软件开发等).比特币搜索引擎.开发一个CSS框架来取代Bootstrap.从Instagram上找出最有魅力的那些人.开发一个实时访问

程序员的开发项目总是半途而废

程序员的开发项目总是半途而废 很多程序员的项目常常半途而废.他们有那么多的好点子,但是很多都流于空想.几乎每一个软件开发者都有一个这样的文件夹,里面很多都是些还没完工的项目,而这些程序里有不少在它诞生初期真心是个超棒的点子.和这些人一样,我也有很多好主意,有的甚至就是现在有些企业在用的.比如正决定着在eBay上还是在Amazon上做电子商务获利.做一个以业务为基础的社交网络(水管业.电子行业.软件开发等).比特币搜索引擎.开发一个CSS框架来取代Bootstrap.从Instagram上找出最有

iOS开发项目篇—11item

iOS开发项目篇—11item 一.UINavigationItem 1.获得方式 self.navigationItem     // self是指控制器 2. 作用 可以用来设置当前控制器顶部导航栏的内容 设置导航栏中间的内容 self.navigationItem.title self.navigationItem.titleView 二.UIBarButtonItem 1. 用在什么地方 设置导航栏左上角的内容 self.navigationItem.leftBarButtonItem

NGUI研究之制作转圈的技能CD特效

 昨天想做一个技能CD转圈的特效,花了大把的时间去用meshRender组件想通过三角形依据数学算法来绘制一个圆形的网格.通过动态绘制圆形网格的方法来实现技能CD特效.奶奶的昨天我研究了一晚上,最终做出来了.但是今天突然发现NGUI已经实现这个功能了,,真是坑爹啊啊---,在技能图标上面放个半透明的精灵,用来做技能冷却的特效,例如以下图所看到的,我就用NGUI中的图标来带取代.对事件方法不明确的看NGUI研究之三种方式监听NGUI的事件方法 然后改动一下特效的精灵类型,它是在技能图标上面悬浮

[原]敏捷开发-项目启动

确定人员,保持小而灵活的团队. 先行开发确定需求,不浪费所有人的时间,实际是把整体的开发时间都提前了. 相对于瀑布流,团队所有成员一次把项目的所有细节都研究详细了,再开始开发工作,这里面有个弊端是,我们发现每次需求过来的时候,通常情况下大部分的逻辑设计都还是相对清晰的,而卡出的地方往往占少部分,完全没必要把所有的人都拉到一起确认,开会是个很耗时间的东西,一两天很容易就废掉了. 这种情况下,其实那些“大部分清晰的需求”是可以先行开始,只需要项目负责人或者Scurm master来和产品确认有问题的