ugui源碼地址

Ⅰ Unity怎麼用UGUI製作圖表，柱狀圖，餅圖

XCharts純源碼繪制、可高度定製的UGUI繪圖插件；支持折線圖，柱形圖，餅圖，雷達圖等。

Ⅱ 如何使用vs2012單步調試uGUI

使用自己編譯的uGUI

1.首選下載uGUI代碼，如何下載參考相關文檔。

2.使用vs2012打開解決方案UISystem.sln，看到三個工程。

UnityEditor.UI工程：生成Edtior/UnityEditor.UI.dll，主要是包含各UGUI控制項在Editor的Inspector功能。

UnityEngine.UI工程：生成Standalone/UnityEngine.UI.dll，主要是UGUI在發布包中使用的功能。

UnityEngine.UI-Editor工程：生成UnityEngine.UI.dll，主要是UGUI在編輯器中使用的功能。

3.修改DLL輸出路徑

UnityEditor.UI工程輸出路徑：d:

UnityEngine.UI工程輸出路徑：d:

UnityEngine.UI-Editor工程輸出路徑：d:

到這步按F7就可以把uGUI代碼編譯出的dll給unity使用。

uGUI單步調試

1.使用工具pdb2mdb.exe生成mdb文件

不過在Unity中還是無法調試到uGUI的源代碼中，因為剛剛編譯出來的調試信息文件是pdb，而mono的調試信息文件是mdb。因此我們需要用pdb2mdb工具將它進行。轉工具：d:.5pdb2mdb.exe

把CMD工作目錄轉到d:。然後開始轉換。

但還是報錯了：

未經處理的異常:System.IO.FileNotFoundException:未能載入文件或程序集「Mono.Cec

il,Version=0.9.5.0,Culture=neutral,PublicKeyToken=0738eb9f132ed756」或它的某

一個依賴項。系統找不到指定的文件。

在Pdb2Mdb.Driver.Main(String[]args)

解決方法：

下一個新的pdb2mdb.exe工具

https://gist.github.com/jbevain/ba23149da8369e4a966f

終於成功了：

可以看到目錄d:下生成了UnityEngine.UI.dll.mdb文件。

2.開始單步調試：

A.下好斷點。

B.運行Unity3D測試例子。

C.把dll附加到unity中去

4.做相應操作觸發斷點。（我這里是點擊測試例子的按鈕）

Ⅲ unity3d ngui uibutton 可帶參數嗎

最近寫的游戲中UI部分用的NGUI，感覺NGUI真心沒UGUI好用啊，功能封裝的不全，想要什麼功能還得去翻源碼。比如PopList加滑動。。。
今天說說UIButton的點擊事件，最簡單的拖動就不說了，功能很雞肋，一是不好維護，而是很多情況下我們要動態生成一些button並且對這些button回調，NGUI中封裝了一個EventDelegate類用來添加回調函數，再把很多個EventDelegate封裝成一個List委託鏈實現一對多的觀察者模式。所以如果我們想讓UIButton帶參傳遞，關鍵是如何向EventDelegate中封裝參數。
我們先看看EventDelegate的執行方法，核心代碼就一句：
mMethod.Invoke(mTarget, mArgs);

顯然我們在實例化EventDelegate時，至少給他一個方法名，讓他的mMethod可以通過反射找到方法，至少給他一個類實例，讓他知道執行哪個實例中的方法，mTarget在聲明時規定MonoBehavior類型，顯然我們還要給他一個組件實例，正好對應我們想要接受回調函數的那個實例。而第二個參數mArgs正是我們需要的回調參數，那我們再看看EventDelegate中是否有參數傳遞的相關屬性或者方法。
幸運的是EventDelegate類中封裝了參數類，類似通知模式通過強轉Object可以傳遞各種類型的參數。

Ⅳ ugui怎麼獲取到當前拖拽事件的對象發

這個draggable插件確實沒用過，你應該多查查文檔、API啥的，應該都有提供一些參數、返回值什麼的，甚至可以讀讀它的源碼
至於e.target，你可以理解為"當前對象"，當前操作的對象，比如現在有個叫做btn1的input[type=button]，你點擊這個按鈕，這時候e.target就是這個button

Ⅳ unity editorscencemanager 怎麼使用

總的來說，unity沒有啥天坑。只要肯研究，後期都能改進，也都不會影響到上線。
小坑太多，說不完。unity上手容易坑太多，基本事件機制，生存周期，場景和資源管理，mono虛擬機的gc機制都是坑。

要說的話，真正影響到架構的是（排序）
1. 是否要用lua
2. （對於需操作的游戲）客戶端游戲如何做戰斗驗證

-----------------------------------------------------
公司的話，推薦：
參加Unity年會
購買Unity的官方支持問答平台，人有源代碼，還能找總部

-----------------------------------------------------
下面列舉小坑吧。不建議都繞開，畢竟沒有那麼多時間做前期調研的。
對應版本Unity4.x

1. 客戶端程序層面
總的來說C#超級給力的，不過別玩脫了

1) mono虛擬機gc
Unity的mono虛擬機使用不分代的gc演算法，臨時對象積攢起來，導致重量級GC游戲頻繁卡頓。
Unity官方：認真review每幀20B以上，以及一次2K以上的GC Alloc的行為。傳聞：Unity5會改進。
推薦閱讀：
Gamasutra: Wendelin Reich's Blog
評價：請像C++一樣精確了解各種行為的gc，foreach 都不要隨便用。嚴重，但游戲是可以卡巴卡巴上線的。後期一位核心開發人員修2~3周。

2) 蘋果aot編譯問題：模板問題
mono在蘋果上採用aot將C#編譯為靜態代碼。首先，依賴於動態代碼生成的復雜模板容易運行時崩潰；其次，mono會將客戶端生成一個庫。模板代碼實例化容易膨脹導致該庫超過40M而無法鏈接。
實戰：碰到了改寫法吧。不過我本人是靜態類型檢查派的。

3) 少用coroutine
yield只支持try--finally，與異常體系兼容性極差；難以提供返回值；非同步本身是非線性的，很難保證邏輯完備
實戰：復雜非同步邏輯用狀態機。不致命，多修bug也能抗過。

4) 自行處理配置數據序列化
嚴重影響配置讀取速度。C#自帶的xml序列化很慢，自帶的二進制序列化也不夠快。
實戰：打包配置考慮protobuf或者代碼生成器。中後期一周左右。

5) 反射
手機上jit情況下，第一次反射一個類很慢。亂用足夠影響啟動速度。

6) 本地化
如果公司習慣於做海外市場，一開始就可以考慮全套本地化方案。後期改需要一個人1~2個月工作量。

2 資源優化
Unity資源優化，一個靠譜的TA很重要。

1) 資源內存佔用
512內存機器能用的資源大概只有50~60M。
需透徹研究貼圖。考慮換皮怪資源復用、UI的圖集合理化。
沒有UI優化經驗的話，強烈建議一個核心開發死跟，像摳代碼優化一樣優化圖集總結經驗。這個後期很難收場。
每個粒子發射器佔用10K內存；有些項目在動畫上會有內存問題。

2) 關注資源包大小
最大的是貼圖和骨骼動畫。貼圖關注內存即可。骨骼動畫可以佔到模型的一半大小，重做的話有各種優化方案。但超標後期也很難收場。

3) 依賴打包
Unity4.x和Unity5完全不同。其中Unity4.x機制龐大繁雜容易錯，要有心理准備。扯一些要點：
* 一定要搞清其內存佔用和生存周期。要實測，特別容易跌眼鏡。
* 每個API都有坑。我個人目前推薦壓縮模式、LoadFromCache，此時不能拆太碎。戰斗前預載入。
* shader載入慢，應當放入依賴包
* bundle不能重名

4) 場景、drawcall、camera
場景面多了考慮動態batching
不同材質透明物體（例如粒子）穿插可能引起drawcall暴增。
camera是重型對象，越少越好

5) svn
資源選Text模式、顯式保存.meta，便於版本管理。資源分人或者鎖了改，規避沖突。

3 Unity
和Flash一樣容易學的3D編輯器

1 ) 事件機制
Unity事件機制很不好用。單個對象，Awake，Start，Enable調用時機相當復雜。Unity完全不保證多個對象的事件執行順序，導致很多人繞開Start。不恰當的使用事件，很容易導致父子對象不在同一幀出現，畫面不幹凈。
Destroy操作是延遲的，對象會活到幀的結尾，然後必定銷毀。庫級設計時，必須考慮到這一點(例如對象池/動畫庫)。

2) 資源管理
只說Unity4.x。合理做法是依賴很卡的UnloadUnusedAssets、LoadScene清理無引用資源（另注意前者是非同步的），或者Bundle.Unload(true)，這些方案各有限制。試圖更細粒度手工清理的困難在於，並不存在系統性文檔解釋Unity資源的分類和生存周期，且Destroy操作很保守。例如，銷毀mesh時，並不會銷毀material、texture，更不會清理腳本資源。
此外，特定的普通操作會造成資源克隆。例如訪問Renderer.meterial，Animation.AddClip。

4 NGUI
久經驗證的掉鏈子王。新項目也可以嘗嘗uGUI

1) panel重繪
widget改變後，所在panel需要生成多邊形，很慢，坑新人沒商量，注意合理分panel。panel中多邊形過多會爆（貌似是65535個頂點？）。
uGUI原理相同，就是c代碼比C#快不少。

2) panel渲染順序
搞清楚ui上放置3D物體咋辦，ui如何和特效混合排序。

3) 策劃/美術ui規范
潛規則很多。Anchor、動畫不可作用於同一個物體。widget必須是panel的子節點，不然他就會自己造panel，經常搞出亂子。再加上上面的panel規則等，要策劃美術折騰ui可費神了。
項目組自製UI編輯器自然是極好的，不過不一定必要。

4) 創建速度慢
由於序列化欄位多，NGUI對象創建可導致卡頓。多狀態對象不要靠隱藏-顯示，而要動態創建。尤其是狀態中包含粒子發生器/Animation，這倆還有內存問題（10K一個）。

5) 與Unity事件機制強耦合
與Unity的事件機制強耦合，不完備，容易有bug。例如，panel繪制依賴於LateUpdate。coroutine中同時關閉舊界面，創建新界面，此時當前幀 LateUpdate 已過，表現為有一幀畫面為空白。

----------------------------------------------------------------------------------------
正文分割線

Q:回答Ye Deng在評論區的問題 「能詳細說說使用 UnloadUnusedAssets()、LoadScene() 等等 APIs 的細節嗎? 有沒有替代方案 」。

A: 需要區分 SceneMemory和Asset。Instantiate出的GameObject及其Component屬於SceneMemory。貼圖、Mesh、Shader、自定義Component代碼、AnimationClip等，還有AssetBundle中的GameObject及其Component屬於Asset。

Destroy僅刪除SceneMemory對象，不刪Asset。

UnloadUnusedAssets、LoadScene 檢索代碼堆（不檢查棧），刪除所有未引用的Asset。

AssetBundle.Unload(true) 刪除bundle自有Asset。

DestroyImmediate 刪除Asset

說一下UnloadUnusedAssets慢的原因。核心問題在於，Unity希望C#代碼可以引用資源，而且能維持其資源生命周期。然後Unity決定每次UnloadUnusedAssets都去掃描所有C#對象！這個挺慢的。

從API看，下面是比較原汁原味Unity的模式，都避免了關卡中間UnloadUnusedAssets：
A. 靜態關卡
關卡進入前載入所有資源，在關卡結束後一次性清理。特別的，Unity覺得你應該使用Scene，他的lightmap、navimesh都是與Scene綁定的。這種情況下，都不需要調用UnloadUnusedAssets()。優點是關卡非常流暢，但是關卡必須是有限大小，有限內容。

B. AssetBundle為單位管理動態資源
動態資源放到AssetBundle中，不再使用時，用Unload(true)徹底刪除Asset。缺點是和A方案比起來載入可能會卡；此外不卸載的bundle本身，合到一起經常有10~30M的額外內存佔用。

具體游戲，怪物、特效、UI、玩家用A還是B就是權衡問題了。

最後，如果覺得Unity不好，可以考慮全手動管理資源，能繞開一些限制，多榨一些性能。如果項目可以有一個人專門深度優化技術，可以考慮嘗試，時間兩個月起，也會引入不少bug。不少項目是主程做這事，也有讓較厲害的程序做這的。

Ⅵ 如何快速優化手游性能問題

一、UGUI簡介

UGUI是Unity官方推出的UI系統，集成了所見即所得的UI解決方案， 其功能豐富並且使用簡單，同時其源代碼也是開放的
相比於NGUI，UGUI有以下幾個優點：
1. 所見即所得的編輯方式，在Scene窗口中即可編輯。
2. 智能的Sprite packer可以將圖片按tag自動生成圖集而無需人工維護，生成的圖集合並方式比較合理，無冗餘資源。
3. 渲染順序與GameObject的Hierarchy順序相關，靠近根節點顯示在底層，而靠近葉子節點顯示在頂層；這樣的渲染方式使得調整UI的層級比較方便和直觀。
4. RectTranForm及錨點系統更適合於2D平面布局，並且非常方便多解析度屏幕自適配。
二、UI製作規范和指導方法

本文是關於UGUI優化的，或許你會覺得UI的製作規范及指導方法與優化無關，其實很多性能問題往往是資源的不合理使用造成的，比如使用了尺寸過大的圖片、引用了過多的圖集以及載入了不必要的資源等。如果從設計和製作UI一開始就遵守特定的規范，則可以規避不必要的性能開銷。筆者根據參與的多個項目總結了以下幾點通用的規范和指導方法（這些規范適用於所有項目，不管你使用UGUI還是NGUI）。
1.合理的分配圖集
合理的分配圖集可以降低drawcall和資源載入速度；具體細節如下：
同一個UI界面的圖片盡可能放到一個圖集中，這樣可以盡可能的降低drawcall。
共用的圖片放到一個或幾共享的圖集中，例如通用的彈框和按鈕等；相同功能的圖片放到一個圖集中， 例如裝備圖標和英雄頭像等；這樣可以降低切換界面的載入速度。
不同格式的圖片分別放到不同的圖集中，例如透明(帶Alpha)和不透明（不帶Alpha)的圖片，這樣可以減少圖片的存儲空間和佔用內存。(UGUI的sprite packer會自動處理這種情況）
2.resources目錄中應該只保存prefab文件，其它非prefab文件（例如動畫，貼圖，材質等）應放到resource目錄之外

Ⅶ 如何優化 canvas cpu佔用

一、UGUI簡介

UGUI是Unity官方推出的UI系統，集成了所見即所得的UI解決方案， 其功能豐富並且使用簡單，同時其源代碼也是開放的，下載地址：
相比於NGUI，UGUI有以下幾個優點：
1. 所見即所得的編輯方式，在Scene窗口中即可編輯。
2. 智能的Sprite packer可以將圖片按tag自動生成圖集而無需人工維護，生成的圖集合並方式比較合理，無冗餘資源。
3. 渲染順序與GameObject的Hierarchy順序相關，靠近根節點顯示在底層，而靠近葉子節點顯示在頂層；這樣的渲染方式使得調整UI的層級比較方便和直觀。
4. RectTranForm及錨點系統更適合於2D平面布局，並且非常方便多解析度屏幕自適配。
二、UI製作規范和指導方法

本文是關於UGUI優化的，或許你會覺得UI的製作規范及指導方法與優化無關，其實很多性能問題往往是資源的不合理使用造成的，比如使用了尺寸過大的圖片、引用了過多的圖集以及載入了不必要的資源等。如果從設計和製作UI一開始就遵守特定的規范，則可以規避不必要的性能開銷。筆者根據參與的多個項目總結了以下幾點通用的規范和指導方法（這些規范適用於所有項目，不管你使用UGUI還是NGUI）。
1.合理的分配圖集
合理的分配圖集可以降低drawcall和資源載入速度；具體細節如下：
同一個UI界面的圖片盡可能放到一個圖集中，這樣可以盡可能的降低drawcall。
共用的圖片放到一個或幾共享的圖集中，例如通用的彈框和按鈕等；相同功能的圖片放到一個圖集中， 例如裝備圖標和英雄頭像等；這樣可以降低切換界面的載入速度。
不同格式的圖片分別放到不同的圖集中，例如透明(帶Alpha)和不透明（不帶Alpha)的圖片，這樣可以減少圖片的存儲空間和佔用內存。(UGUI的sprite packer會自動處理這種情況）
2.resources目錄中應該只保存prefab文件，其它非prefab文件（例如動畫，貼圖，材質等）應放到resource目錄之外
因為隨著項目的迭代，可能會導致部分資源（動畫，貼圖）等失效，如果這些文件放在resource目錄下，在打包時，unity會將resource目錄下文本全部打成一個大的AssetBundle包（非resouce目錄下的文件只有在引用到時才會被打到包里），從而出現冗餘，增加不必要的存儲空間和內存佔用。可以通過以下代碼（Mac環境下）在控制台窗口中查看當前目錄下所有非prefab資源的代碼：find . -type f | egrep -v "(prefab|prefab.meta|meta)$"
例如在筆者的一次掃描中，發現在了如下結果：

3.關卡內的UI資源不要與外圍系統UI資源混用
在關卡內，需要載入大量的角色及場景資源，內存比較吃緊，一般在進入關卡時，都會手動釋放外圍系統的資源，以便使關卡內有更多的內存可以使用。如果戰斗內的UI與外圍系統的UI使用相同圖集里的圖片，則有可能會使得外圍系統的圖片資源釋放不成功。對於關卡內與外圍共用的UI資源需要特殊處理，一般來說復制一份出來專門給關卡內使用是比較好的選擇。
4.適當的降低圖片的尺寸
有時UI系統的背景可能會使用全屏大小的圖片，比如在Iphone上使用1136*640大小的圖片；使用這樣尺寸的圖片代價是很昂貴的，可以和美術同學商量適當的降低圖片的精度，使用更低尺寸的圖片。
5.在android設備上使用etc格式的圖片
目前，幾乎所有android設備都支持etc1格式的圖片，etc1的好處是第個像素點只戰用0.5個位元組而普通rgba32的圖片每個像素點佔4個位元組，也就說一張1024*1024圖片如果使用rgba32的格式所佔用的內存為4M而etc1格式所佔用的內存僅為0.5M。但是使用etc1格式的圖片有兩個限制——長和寬必須是POT的（2的N次方）並且不支持alpha通道，因此使用etc1時需要額外的一張圖來存儲alpha通道，並且使用特殊的shader來對alpha采樣。具體的細節可參考：
6.刪除不必要的UI節點、動畫組件及資源
隨著項目的迭代，可能有部分ui節點及動畫已經失效，對於失效的節點及動畫一定要刪除，在很多項目中，有部分同學為了方便省事，只是將失效的節點及動畫disable了。這樣做雖然在運行時不會對cpu造成太多負擔，但是在載入時會增加不必要的載入時間以及內存佔用。對於廢棄的UI圖片資源，雖然未放到Resource目錄最終不會打到包里，但是在Editor模式下仍然會打到圖集中從而影響優化決策。筆者寫了一個掃描未使用到UI貼圖資源的工具，代碼地址：；
另外，對於廢棄的腳本，可能還會有某些對象持有對它的引用，而載入這樣的對象也比較耗時，筆者也寫了一個掃描廢棄腳本的工具，代碼地址：
三、CPU優化

一般來說，優化cpu性能應該先用profiler定位到性能熱點，找到消耗最高的函數，然後再想辦法降低它的消耗。經過筆者多次使用profiler對UGUI的分析來看,其CPU性能開銷高主要原因之一是Canvs對UI網格的重建，有很多情況會觸發Canvas對網格的重建，例如Image,Text等UI元素的Enable及UI元素的長、寬或Color屬性的變化等。Canvas中UI Mesh頂點較多的話，則該項將會出現較高的CPU開銷。在Unity的Profiler中則對應的是Canvas.SendWillRenderCanvases或Canvas.BuildBatch佔用過多的時間。
Canvas.BuildBatch主要功能是合並Canvas節點下所有UI元素的網格，合並後的網格會緩存起來，只有其下面的UI元素的網格發生改變時才會重新合並。而UI元素的網路變化主要是因為Canvas.SendWillRenderCanvases調用時，rebuild了Layout或者craphic。該函數的調用過程時序圖如下：

該過程由CanvasUpdateRegistry監聽Canvas的WillRenderCanvases（上圖中1）而執行,主要是對前標記為dirty的layout和craphic執行rebuild。引起layout和graphic的dirty主要原因是因為Canvas樹形結構下的UI元素發生了變化（例如增加刪除UI對象，UI元素的頂點，rec尺寸改變等）調用了Graphic.SetDirty(實際上最終都會調用CanvasUpdateRegistry.)。
在rebuild layout之前會對Layout rebuild queue中的元素依據它們在heiarchy中的層次深度進行排序（上圖中的2），排列的結果是越靠近根的節點越會被優先處理。
rebuild layout（上圖中的3）,主要是執行ILayoutElement和ILayoutController介面中的方法來計算位置，Rect的大小等布局信息。
rebulid graphic（上圖中的4）,主要是調用UpdateGeometry重建網格的頂點數據（上圖中5）以及調用UpdateMeterial更新CanvasRender的材質信息（上圖中6）。
基於以上UGUI的網格更新原理，我們可以做以下優化：
a.使用盡可能少的UI元素；在製作UI時，一定要仔細查檢UI層級，刪除不不必要的UI元素，這樣可以減少深度排序的時間（上圖中的2）以及Rebuild的時間（上圖中的3，4）。
b.減少Rebuild的頻率，將動態UI元素（頻繁改變例如頂點、alpha、坐標和大小等的元素）與靜態UI元素分離出來，放到特定的Canvas中。
c.謹慎使用UI元素的enable與disable,因為它們會觸發耗時較高的rebuild（圖中的3、4），替代方案之一是enable和disableUI元素的canvasrender或者Canvas。
d.謹慎使用Text的Best Fit選項，雖然這個選項可以動態的調整字體大小以適應UI布局而不會超框，但其代價是很高的，Unity會為用到的該元素所用到的所有字型大小生成圖元保存在atlas里，不但增加額外的生成時間，還會使得字體對應的atlas變大。

Ⅷ 游戲開發需要懂幾種語言

游戲開發大致可以分為PC端游戲開發和移動端游戲開發，但不管怎樣都離不開這三大語言，即Java、C語言和C++語言，用來的開發引擎主要就是Unity3D和Cocos，比較熟悉的還是unity.
Unity過去主要針對3D游戲開發的市場，目標是佔領整個游戲開發團隊。72%的以游戲開發類別為首要工作的參與者選擇Unity作為他們的首選游戲開發工具。採用Unity目標定位於桌面平台的開發又佔了一半，這可顯然比均值高很多，此外還有一些其他的垂直功能，例如視覺結構，軍事模擬和教育等Unity都迎合了設計者的需求。
編譯原理之類的都需要學習;動畫做工具），STL，而不是程序。這些只是屬於基礎知識，只有引擎並不是一個游戲，比如說一個網游裡面有10個副本：
網路游戲裡面有副本系統。

如果你單純想知道游戲引擎相關的技術，線性代數，撤銷，你說的操作系統，數據結構，有了引擎。

比如說你會需要了解3DSMAX Script（用來給美術，自動存檔，場景，裡面怪物的模型，不過根據不同的游戲類型可以設計出各種不同的開發工具，等等之類的;粘貼NPC;動畫，游戲本身事實上是數據驅動的，叫副本編輯器，統籌方法，目前的情況游戲程序員大部分的時間都是在做各種工具，設計模式，副本的關卡設置。

理論上講戲編程開發包含的內容太廣了，主要集中在對DX API的了解，設置關卡，而且有了工具，那麼副本的製作就需要有一條製作流水線。

======================================
補充回答樓主的問題，游戲裡面要實現20個不同的副本，等等之類的，則和工具沒什麼關系，很難做到完美的數據驅動，而工具則和具體的游戲類型相關的，我舉這么個例子，另外需要自己學習的就是了解一下游戲開發中一般常用的一些方法和工具流水線，版本控制等等之類的，比較重要的還有線性代數;重做，而不是通過程序員寫代碼來實現的，這個工具本身和引擎無關。工具編寫又牽扯到很多其他方面的編程技巧（和游戲本身無關的）比如說復制，編寫makefile，物理，設計模式;美術可視化的在場景裡面放置機關，裡面可以讓策劃。那麼基於以上的一些策劃，圖形學，這10個副本都是通過各種工具配置出來的，演算法，因為引擎是更加通用的，等等，比方說副本的美術場景資源，我們就需要開發一個工具;軟體信息，獎勵系統，Office系列軟體的COM介面（用來給策劃做工具），還是需要製作。

Ⅸ 缺少CUGUIIrrlichtrenderer.dII 在哪下載

你好!

如果你需要的是CEGUIIrrlichtRenderer.dll

你以>CUGUIIrrlichtrenderer.dII>為搜索關鍵詞>點>網路一下>前3個>點擊進去都可以下載

如果不是你要找的,網路和谷歌上都沒有你說的CUGUIIrrlichtrenderer.dII的下載地址,

你只能看看是哪個軟體會用到它,重新安裝一下試試,或者找個完整版重裝一下,

Ⅹ 怎麼讓unity的play動畫不全屏顯示

什麼是play動畫？

你的意思是按下那個三角箭頭以後不讓它最大化顯示Game視圖嗎？

如果是這樣的話，把Maximize on Play點掉就好了。