渲染順序 Rendering order

最近有同事在研究NGUI與UGUI的渲染順序關係（假如用同一個camera下），不過今天不是想講這個議題，而是來講講渲染順序。
當然也是有參考一些網路上的文章，本文主要是我看完後吸收到的結論。

以下圖片是實作渲染順序，如果看不懂…請再跟我說。(以下皆使用2017.4.3f1)

[工具]替換Component(Script)小工具

終於抽出時間來做些方便的小工具，其實也是為了要幫助自己快速優化專案的東西。
功能：可以對所有物件上所指定的script 同時替換成另一個script。但是限制是繼承同一個script~(例如NGUISPritePlus(繼承NGUISprite)可以取代NGUISprite)

[Vue2][練習]使用requireJS建立Component+$emit語法

this.$emit('event name', value);
子層向父層呼叫Method的方法。

[Vue2][練習]MENU列舉 - a標籤範例

【筆記】Unity5.4.3取得Animator現在的執行動畫(AnimatorState)的播放影格/時間

Animator m_FirstAnim, m_SecondAnim;
m_FirstAnim.Play("Loop", 0, 0);
.....
.....
float myTime = 0;
AnimatorStateInfo animationState = m_FirstAnim.GetCurrentAnimatorStateInfo(0);
float newNormalIzedTime = animationState.normalizedTime - (float)System.Math.Truncate(animationState.normalizedTime);
AnimatorClipInfo[] targetAnimatorClip = m_FirstAnim.GetCurrentAnimatorClipInfo(0);
if (targetAnimatorClip.Length > 0)
{
  myTime = targetAnimatorClip[0].clip.length * newNormalIzedTime;
}
else
{
  myTime = newNormalIzedTime;
}
m_SecondAnim.Play("Loop", 0, myTime);

Inspecter 基本架構紀錄

[CustomEditor(typeof(Tool))]
public class ToolInspecter : Editor
{
  protected Tool m_Tool;
  /// 

  /// Component每一次顯示在Inspector上就會重新呼叫一次
  /// 
  private void OnEnable()
  {
     //DO init
     m_Tool = target as Tool;
  }

  /// 

  /// Component從Inspector上移除的瞬間執行
  /// 
  private void OnDestroy()
  {
     //Do origin
  }

  /// 

  /// 該Component每一次有改變就會呼叫一次
  /// 
  public override void OnInspectorGUI()
  {
     //Do Draw GUI
     DrawDefaultInspector();
  }

Adapter Pattern：組合兩個不相干的執行需要一個轉接器

概念

當螢幕只有D-SUB，但卻要接主機只有DVI插孔的顯示卡時候，需要轉接器來轉換傳送訊號，這種改變既有內容去轉換需要結果時，就需要它。
很多人會想，那只要共同有一個Interface去繼承就好啦！
但是像是D-SUB這種已經定型的產品架構，你無法再重新改變它的定義與執行內容，你只能取出它並且改為新產品需要的資訊才能產生結果。
在這個之中，D-SUB被稱為Target，轉換對象；DVI被稱為Adaptee，適配者。

假如功能相差太多的兩種功能/產品，或是適配者有著轉換對象沒有的plugin，那就不適用這種設計模式。

動態設定Private Member時候遇到System.Reflection.MonoField錯誤

一般來說，要設定私人變數時，只要這麼寫通常可以順利進去：

var tProp = OverrideCtrl.GetType().GetField("name", BindingFlags.NonPublic | BindingFlags.Instance);
tProp.SetValue(tPorp, "new name value");

但若設定的是繼承MonoBehaviour的物件的話，請在setValue(Object, Value)中，把Object直接指向物件。

public GameObject TargetObject = null;
private void ReplaceObj(){
  var tProp = OverrideCtrl.GetType().GetField("monoObject", BindingFlags.NonPublic | BindingFlags.Instance);
  tProp.SetValue(OverrideCtrl, TargetObject);
}

【筆記】List用ToArray轉成Array的理由

最近為了煩惱要不要把List轉成Array傳給function去做處理，爬了一些文，很多年前就有回答：C# List.ToArray performance is bad?


底下有個回答寫的很清楚：

Reasons to call ToArray()

• If the returned value is not meant to be modified, returning it as an array makes that fact a bit clearer.
• If the caller is expected to perform many non-sequential accesses to the data, there can be a performance benefit to an array over a List<>.
• If you know you will need to pass the returned value to a third-party function that expects an array.
• Compatibility with calling functions that need to work with .NET version 1 or 1.1. These versions don't have the List<> type (or any generic types, for that matter).

Reasons not to call ToArray()

• If the caller ever does need to add or remove elements, a List<> is absolutely required.
• The performance benefits are not necessarily guaranteed, especially if the caller is accessing the data in a sequential fashion. There is also the additional step of converting from List<> to array, which takes processing time.
• The caller can always convert the list to an array themselves.

轉換驗證：
C# Convert List to Array - Dot Net Perls

列出來XD

【UGUI】將Particle夾在UI中間

使用UGUI或是NGUI的時候總是有不知道怎麼把mesh或是particle夾在UI之間，最近用了一個小方法來試試看XD
(以下的方法會增加draw call，請慎用啊！)