在開發中，有的時候會遇到一些奇奇怪怪的問題，比如說在3d遊戲開發中需要製作乙個 主角血條或者 敵人血條的時候，一般來說有兩種方式，乙個是 使用 canvas 製作一張 image 進行渲染，乙個是使用 spriterenderer 進行渲染，如果使用 image進行渲染的話每乙個敵人都得引用乙個 image進行實時的渲染，那麼可能效果上沒有區別，但是本質上卻又很多的差異；
image：使用 canvas renderer進行渲染，
sprite renderer：本質是一張半透明的 texture。在匯入的時候被設定成為 sprite，是被渲染到 2d / 3d 場景或者其他介面的。
兩者在視覺上沒有任何區別（都使用預設材質時）。它們預設的渲染也都是在transparent geometry佇列中。
在場景中，你 的 sprite 可以隨便的進行擺放，但是你 的 image 不得不放在 canvas 下邊，這樣來看的話，image 有了一些的侷限性，繼續往下邊走，sprite和image的乙個最重要的區別在於sprites支援網格的自動構造，而ui image的網格始終由矩形構成。
sprite image
上圖中可以看到，ui image創造了乙個緊密的矩形來包裹sprite,而spriterenderer創造了乙個能更好匹配將要渲染的sprite的網格。
sprite由於頂點資料更加複雜，在進行頂點計算時會比image效率更低；
sprite會比image執行較多的頂點著色器運算；
image會比sprite執行更多的片段著色器運算
由於片段著色器是針對每個畫素運算，sprite通過增加頂點而裁剪掉的部分減少了相當多的運算次數，在絕大多數情況下，反而比image擁有更好的效率（尤其是場景中有大量的2d精靈時）。spriterenderer會建立額外的幾何體來裁剪掉多餘的透明畫素區域，從而減少了大量的片段著色器運算，並降低了overdraw；而image則會建立簡單的矩形幾何體。隨著2d元素數量的增加，這種差別會慢慢明顯起來。
因此在2d遊戲開發中，遊戲場景中的元素，應該盡量使用它去渲染。而image應該僅用於ui顯示（實際上即使不考慮效能原因，由於螢幕解析度的變化，image可能會被canvas改變顯示位置和實際大小，如果用於遊戲內元素的顯示，可能會造成跟預期設計不一致的顯示結果，也應該避免使用）。
回到主題，spriterenderer和ui image之間的區別是什麼？顯而易見，sprites的開銷更大，因為它的幾何資料更複雜。但是如果我告訴你頂點操作通常比片元操作開銷小的多呢？尤其對於移動裝置和半透明物件。
Unity遊戲開發效能優化（Sprite優化）
通過減少setpass calls draw calls 數來減少效能消耗 直接進入正題 我隨便在網上找到幾張，將其拖到hierachry面板 此時執行遊戲，觀察game試圖下的stats視窗，此時setpass calls數為4 包括場景的setpass calls 選中需要打包的幾張，選擇為sp...
遊戲開發中敏捷實施
兩個程式設計師的 msn log a 說 2008 09 17 11 23 20 對了，問個咚咚，你們那邊是用scrum 麼？b 說 2008 09 17 11 23 26 對 a 說 2008 09 17 11 26 36 你們也是每天morning meeting 羅？a 說 2008 09 1...
遊戲開發中的資料池問題和改進
之前開發遊戲的時候，為了能夠在任意地方都能訪問到資料，一般的做法是建立乙個資料池，然後把想要的資料全部放到資料池類中。資料池的寫法一般是建乙個名為datapool的單例類，通常情況下對單例的實現一般是這樣的 datapool.h pragma once class datapool datapool...