Dirty Coding Tricks  

Posted by 藍斯洛 in

Dirty Coding Tricks by Brandon Sheffield

================================================

今天在Gamasutra上看到的一篇文章。

遊戲開發有時程壓力,而當我們發現一個很難解的Bug,時間又已經來不及的時候,我們該怎麼辦? 這篇文章就舉出了幾個偷吃步的故事。

頭一個故事就很慘了。

在一個PS2遊戲即將要發行的時候,測試團隊發現,在第一個關卡裡,玩家只是靜靜的站著就偶而會造成crash,而且更不幸的是,是在燒成光碟之後,這個問題才會出現。

於是開發團隊為了解決問題,不斷的修改程式,燒成光碟,然後測試,弄了十幾個小時( 為了等程式 crash,只好拿 World of Warcraft 打發時間.... )。

後來奇蹟出現了。有人發現,一開始攝影機向右轉個90度的話,程式就不會出問題,於是乎,PS2的版本,就在攝影機轉個角度之後,順利通過測試而發片。而已經上架的另外兩個平台的版本,攝影機角度還是維持原先的設計。

我的結論是:寫程式,也需要奇蹟。

第二個故事,真的就是偷吃步了。

遊戲程式中所用到的資源,例如一大堆的檔案,在檔案系統中通常會想些編碼的方式當作索引來存取這些檔案。這個故事裡的團隊很倒楣,他們將檔案的檔名CRC32編碼,同時也將檔案內容做CRC32編碼,用這兩個值組成64位元的索引來存取檔案內容。

開發了兩年,處理了幾萬個檔案,從來沒有發生索引值衝突到的狀況。

可是,它真的發生了。兩個不同內容的檔案,卻有完全相同的檔名(也不知道為什麼要這樣設計....),而且檔案內容在編碼之後也得到相同的CRC32編碼--這下子事情大條。

改檔案系統,改索引方式,都是個大工程,而且誰知道改了之後會不會發生同樣的狀況? 這時候,再怎麼完美的編碼方式,都沒辦法給人信心了。

沒時間了,只好用一個最簡單的偷吃步解決這個問題 -- 把其中一個文字檔案打開,在最後面加一個空格,然後存檔。

於是乎,遊戲如期發行。

 

當然啦,這些方法都不是好的解決方式,而且會帶來後續的問題,不管是程式穩定度還是程式維護上的問題。

不過,對我們老是在有限時間跟疑難雜症打仗的人來說,這些故事是會讓人會心一笑的。

Design Patterns for Game Programming -- Reference Count  

Posted by 藍斯洛 in ,

這是提供入行的新人教育訓練用,我們自己整理的Game Programming中的Design Patterns。我們所想到的第一個項目,就是Reference Count。所以就先將它整理出來了。

既然是寫設計模式,自然必須依照設計模式經典的編排方式來做。

以下進入正題。

 

Design Patterns for Game Programming -- Reference Count

使用時機

遊戲程式中充滿了使用記憶體資源的物件,其中有些物件的特性是,佔用大量的記憶體,又常常重複出現在遊戲中。例如,3D遊戲中的模型、貼圖,2D遊戲中的圖片資源等等。

clip_image002

(場景中重複出現的樹木就包括了重複使用的模型與貼圖) ( Screen-Shot from World of Warcraft )

針對這種物件,我們會將它設計成共享的資源物件,以節省記憶體的使用量。同時,我們也在共享資源物件中,加入參照計數(Reference Count),以便記錄每個共享資源所被參照的數量。

目的

將共用的資源做有效的管理。改善資源與記憶體的使用。

設計實作

clip_image003

架構上主要有三種物件。

Shared Resource :

也就是共享的資源物件,像是貼圖、模型、圖片等。成員變數m_iReferenceCount記錄的就是參照計數,而IncRefCount與DecRefCount則是用來對Reference Count遞增與遞減之用。每個Resource有一個唯一的Key值(例如,資源檔案名稱或是某種編碼後的整數)。

Resource Table :

存放Shared Resource的地方,通常會使用Hash Map、Binary Tree或是其他能夠快速的從Resource Key值搜尋物件的資料結構。

Resource Manager :

做為與應用程式溝通的介面物件。提供兩個最主要的成員函式 : Query Resource 與 Release Resource。

clip_image005

應用程式透過呼叫Resource Manager的Query Resource函式,來取得共享資源。

首先會在Resource Table中搜尋是否有對應Key值的資源存在,如果存在,就將資源的參照計數遞增之後,傳回給應用程式。如果不存在,就產生一個新的資源( 此時新資源的參照計數為1 ),插入Resource Table中,然後傳回給應用程式。

clip_image007

另外,應用程式也透過Resource Manager的Release Resource函式來釋放資源。

首先Manager會先將Resource的參照計數遞減,並且取得結果。如果參照計數小於或等於0,表示已經不再需要這個共享資源,就先從Resource Table中將資源移除,然後,刪除這個資源。

多緒環境下的設計實作

有兩項必須做到Thread-Safe,一是Resource Table的存取,避免多個執行緒同時修改Table內容以及相關的索引資料,另一個則是Reference Count的遞增與遞減計算,避免多個執行緒同時修改,造成資料錯誤。

使用設計上的限制

1. 在這個機制下,共享資源的生成與銷毀都必須是透過Manager的Query / Release來負責,應用程式要避免直接使用new / delete來生成 / 銷毀共享資源。一個可用的設計方式是,將資源物件的建構子與解構子封裝起來不公開,封鎖應用程式對共享資源的new / delete權限,同時宣告Manager為friend class,把權限讓給Manager。

2. 共享資源的Inc / Dec Reference Count操作必須是成對的,否則容易出現Memory Leak ( 當 Inc Reference Count次數大於 Dec Reference Count時 ) 或是使用到無效的指標 ( 當 Inc Reference Count次數小於 Dec Reference Count時 )。這項限制,可以透過Smart Pointer的設計來改善。