Silverlight C# 遊戲開發：資源的處理，映像演算法（一）

　　這是一篇暴力的內容，所講之主題雖然可以為Silverlight遊戲開發解決一些問題，但是同樣也會帶來新的其他問題，於是，有意思的事情出現了，到底該怎麼選擇呢？還是依據你的項目進行選取吧，本文純粹使用代碼方式編程，請準備好Visual Studio，不需要Expression。

　　遊戲開發在開始的時候一般不會注意一個重要的細節，就是“特效”，角色也好，情境也罷，可能都不會是最佔用磁碟空間的資源，特效資源，包含了技能釋放的、情境中的，甚至升級也得顯示光線環的，更何況有那種收費的全屏“求交往”特效，如此之多如此之大的資源套件絕對夠咱們頭疼的了，那麼，今天提供一個演算法來為咱們的Silverlight特效資源大瘦身，今次我們只討論有透明的那種特效，沒有透明的特效直接使用關鍵色鏤空即可。

　　首先表明特效一定是圖片動畫序列，以目前的技術來說使用XAML做特效不太實際，一方面特效太過複雜，使用向量來做成本很不划算，另一方面所產出特效的繪製工作效率不及直接用特效工具來做的快又好看（想象一下每個特效20多幀的恐怖狀況吧），最後一個方面，這方面的人才幾乎完全沒有。

　　那麼，我們一起看看一個特效大概會有多大：

　　這個規格是一個簡單的爆破特效，由於使用了半透明，所以只能使用PNG的方式來做，不能用關鍵色鏤空，一共20張512*512圖片787KB，接近1MB，那麼好，打個包還有752KB，很顯然，無論是動態載入還是跟隨發布包一起，都是一個及其佔用磁碟空間的做法，另外一個角度上就是頻寬和記憶體的佔用，如果說可以將這個特效減少到只有100多KB，那就非常爽了。

　　使用JPG來代替PNG就能直接達到這個瘦身效果，同等的特效只有163KB。

　　可是問題來了，jpg畢竟是jpg，沒有png的半透明效果，我們分析一下要想達到類似的效果如何進行處理，參看：

 

 　　分析一下，可以得到一個簡單的結論，就是顏色越黑，越是我們不需要的，而顏色越亮就越有儲存的價值，那麼以此可以推導，是否可以通過顏色的色值來看這個顏色的儲存價值？答案是可以的，在映像儲存中（尤其是最近幾年）顏色以32位方式處理為主，所表示的顏色是8個F，FF FF FF FF，分別代表了ARGB——Alpha、Red、Green、Blue，A是透明度，RGB組成了16777215種顏色，而色值越大顏色就越接近白色，色值越小就越接近黑色，那麼，我們是否可以一個平均方法來取得色彩到底是接近於黑還是白？演算法如下：RGB三色相加平均數就是A的數值，這樣，黑色將被完全去掉，但不會影響那些接近於黑色的顏色，這樣的顏色因為接近於黑，所以透明度也是很高，而我們的特效部分則是以亮光為主，透明度自然就很低了。

　　按照我們的想法實現的效果如下：

 

　　

　　請直接參看Silverlight中的效果，如果運行原始碼請在載入完成後10秒後點擊“開始處理”，這是非常暴力的處理過程，所以請做好心裡準備^0^

原始碼在這裡下載，在這個程式裡，可以研究如何載入一個JPG圖片的列表，然後將其處理成為程式內可用的特效，這個應用對於特效來說至關重要，它能很好節省圖片空間，但是問題也很明顯，處理過程是相當的慢，我使用了一個行為隊列，才不至於直接“卡”在程式運行過程當中，如果你覺得更加暴力一些，可以一次處理完，但將是一個非常消耗系統的過程，如果在遊戲開發中應用，還需要改進演算法，以及處理流程，比如積極式載入和處理，或者分散計算，但無論如何都是一個非常不爽的過程，最好對於演算法可以修正的更加優美，下面的選取部分就是關鍵代碼，演算法上還需要從這上面入手了：）

 

這一次，我們只是僅僅探討了一種可以在遊戲當中對於特效處理的應用方法，高手應該看到處理的效率，我這是純粹的暴力解決方案，可能還有更加巧妙的方式來達到我們期望的效果，但是以我的水平還未尋得好路子，要是有什麼好的方法或者演算法，大家互相交流一下，下一次我們一起研究一些圖片處理上的其他演算法，仍然很！暴！力！