Home

Milo的遊戲開發

開始實作引擎的基本類別

話說之前想做 Collada 滙入,便最基本要有一個內部存放 Collada 滙入後的資料。這個「雙休日」(內地常用語) 就留在家中乖乖寫程式……寫不出的時候也看了十幾集動畫。

架構上參考了之前看過的 Unity,採用 Component 型式。目前實現的幾個類別的關係如下圖:

採用 Component 架構的一個好處是,減少了傳統 Scene Graph 的類別繼承和節點 (node) 數目。一個實體 (entity, 有些引擎稱為 Game Object) 可以有 Mesh 元件,也可以同時加入腳本、碰撞物件等元件。

實作過程中出現許多問題,和大家 (及將來的自己) 分享一下。

繼續閱讀

希望在家繼續做遊戲,首先還是做 COLLADA 吧

說點近況。自從四月回港參加好友的婚禮,帶了台 Xbox360 回上海後,便花了許多時間「研究」遊戲,包括我公司的幾個作品,之後也「研究」Wii 的各種遊戲。家人回港後獨自一人,還看了蠻多的動畫和最近的奧運。之前在家中做的項目便擱置了將近半年……雖然也不是完全沉醉於「研究遊戲」和其他娛樂上,書和文獻也有看一些,但還是覺得生活應該得更充實一點。這幾天又再想繼續之前的項目。

第一件發現的是,我的記憶能力真的很有限。過了五個月,幾乎完全忘記了之前的想法、進度等等。全靠閱讀這個 Blog 才知道五個月前的 Milo 在想甚麼。「外置記憶體」真是很重要,而且可以用來認識過去的自己。不知道還能否找到十年前在網上發表的日記,看看當時頗年少氣盛的自己。

讓 COLLADA 作為新起點

之前的項目主要做了非常基楚的混合語言、跨平台圖像及工具的嘗試。本來想繼續做一點輸入及物理,以完成整個遊戲循環,做到一點互動的機制。但是,對比較喜歡電腦圖像編程的我來說,始終敵不過引誘,想載入一些比較好看的3D模型,並且做一些實驗。因此,暫時想先做載入3D模型的部份。

要載入3D模型,COLLADA 似乎是最好的選擇。COLLADA 是一個公開的三維數據 XML 交換格式。目前許多三維圖像軟件(如 3D Studio Max、Maya、SoftImage 等等)都有滙入滙出 COLLADA 的功能 (原生支持或透過插件),可以省下自行編寫插件的時間。

要在程式中支持讀寫 COLLADA 格式,最簡單的方法是使用 COLLADA 的程式庫。流行的程式庫有兩個: Feeling Software 的 FCollada 和Sony Entertainment 的 Collada DOM。兩個皆為 C++ 開源項目,並且皆使用 Document Object Model (DOM) 的方式存取 COLLADA 資料。

FCollada 的優點在於 API 比較簡單、可同時讀寫不同版本的 COLLADA 格式。而且,現時流行的 ColladaMax 和 ColladaMaya 插件都是 Feeling Software 採用 FCollada 編寫的,兼容性可能比較好。可是,一個壞消息是,Feeling Software 已於本年3月停止 FCollada 的更新,現在由一個開源隊伍維持該項目

Collada DOM 是 Sony Entertainment 的產物 (事實上 COLLADA 也是由 Sony 發起的標準)。Collada DOM 的一個特別之處是,DOM 的 API 是由 COLLADA 的 Schema 用程式生成的。這樣的好處是,COLLADA 格式的版本更新只需要運行程式就能得到新的 API。不過這是雙面刃,Collada DOM 的缺點之一就是不能同時讀寫不同版本的 COLLADA 檔案。

經過一番比較後,現時選擇了 Collada DOM。它的一些吸引之處包括:

  1. 可選擇 XML 解析器
  2. 直接支持 Windows、Linux、OSX 和 PS3
  3. 包含一個 Collada RT 的開源項目,內有一個基於 OpenGL 的 COLLADA 檔案檢視器

最後一點最吸引我。這個檢視器除了支持基本的 geometry ,還支持 Skin、Skeleton、Animation、Collada FX 等等。這是一個很有參考價值的例子,我可以跟據這個例子去使用 Collada DOM。相對地,FCollada 並沒有這樣全面的開源例子。

昨晚編譯了 Collada DOM ,也測試了 Collada RT 檢視器和看了一些文檔。但是,要轉換 Collada 格式去引擎內部格式的話,目前的引擎尚欠一個層階式的物件系統。因此,還是要先設計遊戲物件的系統。

P.S. 曾經想過,半年都沒寫到甚麼出來,而科技一日千里,一個人在家裡做這樣的事情有意義嗎?時間雖然是一個問題,但我公司的一個引擎也有七、八年的歷史。如果可以做一個健全的架構,是應該可以與時並進的。一個不能敏捷地修改及更新的項目,很快就會結束它的生命。作為一個學習和分享經驗的平台,這就更沒所謂了。

P.P.S. 我中秋節便會回港陪產,黃金周後才回上海。屆時心理和生活也許又會作出很大的改變。

Larrabee

傳聞聽了很多,但直到最近看了一篇 SIGGRAPH 文章 才真正開始去了解 Intel 的 Larrabee。我的理解還是很淺,有錯請更正。

如果要用一句說話形容我對Larrabee的理解,

把多個順序執行指令(in-order) 的 x86 內核塞進一個芯片,每個內核可執行大部份 x86 指令、16維向量指令及小量新指令,並且有獨立的L2 cache和小量為圖形功能而設的邏輯單元。

對於圖形及高度平行的應用,現時 GPU 比 CPU 更有效率。這是因為這些應用是可以分柝成為較小的獨立工作,分配在 GPU 中的多個硬件單元執行。而在圖形處理上,GPU 加入許多不可編程的圖形功能邏輯硬件,例如紋理取樣 (Texture Sampling)、光柵化 (Rasterization)、內插 (intepolation) 等等。使用數個通用的 CPU 內核去運行,完全不敵數十個為圖形特製的 GPU 內核及圖形功能邏輯硬件。

Larrabee 怎樣挑戰 CPU 和 GPU

Intel 不會輕易言敗,於是發展了 Larrabee。

Larrabee 有多個設計概念:

  1. x86 指令的核心比 GPU 的 shader 指令更普及。只要可編譯成為 x86 指令的程式都可在 Larrabee 上執行,例如目前大量的 C/C++ 程序。
  2. GPU 使用完全獨立的內存,CPU 和 GPU 間的數據流通是不透明的,而且數據的格式很特殊及有限 (例如 vertex/index buffer, texture 等等)。Larrabee 則能直接存取主內存,因此可以使用指針、不同的數據結構、甚至物件導向 (如 virtual function)。
  3. 儘管 DirectX 10 和 11 不斷加入新的 shader 類型,GPU 可編程的地方仍然有限。Larrabee 則希望只有少量的圖形功能邏輯硬件,其餘使用程式,加強可編程性及自由度。
  4. Intel 的 CPU 自 Pentium 4 以來,加入大量非順序 (Out-of-Order, OOO) 執行指令的邏輯,使用電量(熱量!)及晶片面積不斷增加。但數據顯示,一個雙內核 OOO CPU 的晶片面積,其實可以放入 10 個 in-order、每個有 16 維向量處理器的內核。可是,後者的 FLOPS 峰值是前者的 40x 。

Larrabee 和遊戲開發的推測

Larrabee 會對於遊戲開發者有甚麼影響呢?

推測一:無直接影響,Larrabee 只是替代 ATI、NVidia 和 Intel 的 GPU 而已。該文章花了大量的篇幅描述一個在 Larrabee 上執行的渲染軟件 (software renderer)。它是以光柵化 (rasterization) 和目前流行的實時渲染的概念,透過 Larrabee 的各種硬件特性去開發的。最有趣的地方,是他們擷取了 Half-Life2、F.E.A.R.和 Gears of War 的 D3D9 指令及紋理等數據,用 Larrabee 上的軟件渲染。實驗結果是,執行 1600×1200 解像度、60FPS,大概需要 10 至 20 個 1Ghz 的 Larrabee 內核,而且還有非常高的 Scalability。但除了這個結果外,我們可猜測 Intel 有能力及可行性去寫 Larrabee 的 Direct3D 驅動軟件。而且由於 Larrabee 的自由度,Larrabee 可同時支持不同版本甚至不同的圖像API。

推測二: 遊戲用中間件 (middleware) 支持 Larrabee。一些遊戲中間件可以使用 Larrabee 增加效能,例如圖像引擎、物理引擎、人工智能引擎等等。

推測三: 開發者自行編寫為 Larrabee 而設的代碼。從架構上來說,Larrabee 和 Cell 的 SPU 是有相似的地方。開發者可以為遊戲性或特效編寫專用代碼,以製作有獨特遊戲性和特效的遊戲。

推測四: 新的實時圖像渲染時代開始。放棄用了十數年的光柵化式硬體,採用光線追蹤 (Ray tracing) 及其他全局光照 (Global Illumination)。雖然 Larrabee 是第一個試驗品,但若果它成功的話,會完全改寫目前的實時圖像渲染技術,也會帶來很多新的研究。其對實時圖形的影響力可能可以和當年 OpenGL、Direct3D、可編程 GPU 相比。

要做 Visual Studio 樣子的使用者介面? 用 DockPanel Suite 吧!

雖然引擎連1%完成度也沒有,今天開始做遊戲的編輯工具,或者應該說是做工具的原型,一切都當作是實驗吧。

DockPanel Suite 的 Sample Screenshot
(這是 DockPanel Suite 的 Sample,不是 Visual Studio 啊! )

之前已決定採用開源的 DockPanel Suite。它是一個 C# 開源的 .Net 程序庫,基本上做到 Visual Studio.Net 的視窗 docking 功能,包括 tabbed window、split window、float window、docking indicator、auto-hide、讀寫 XML 設定檔等等。我是看到 Cg Composer 的 DLL 才知道有這個 .Net 程序庫,後來也找不到更好的選擇。

繼續閱讀

遊戲開發書庫開張

這幾天花了些時間,整理了一個遊戲開發書庫 (還未完整,有時間會更新及加入短評)。

書對我來說是生活的一部份。自修是最基本的學習方法。有些想讀但未讀,有些讀過又忘記,所以在這個 Blog 裡記錄了一些遊戲相關的書目,方便回顧及展望。當有一天心血來潮,就會重溫過去的書,或者買一些想讀的書回來。

回看這個書目裡面,我第一本買的是 Computer Graphics: Principle and Practice。當時應該就讀高中,書中的內容許多都不能理解。但是一點一滴的累積閱歷,也許可以慢慢地把內容吸收。

在之前數年的工作裡,我可以申請購買許多遊戲相關的書籍(多是頗貴的原文書)。有些讀了一遍,有些我自己沒有讀。現在離開了那些書籍,偶然間,又想重拾起來。

在我這個遊戲書庫內暫時有大約100本書,保守估計平均每本書300頁,而每天能讀 50 頁的話,讀一遍便要 600 天,但這個書庫的內容又會不斷增加…… 突然想起中學讀莊子說的

吾生也有涯,而知也無涯。以有涯隨無涯,殆已!

關於表頭檔的 inline function

閱讀了猴子靈藥《表頭檔要不要?拿速度來換!》後,發覺所言甚是,表頭檔的問題許多時會被忽略。現在寫的代碼,除了考慮執行效率,也應該要考慮編譯效率。

關於在標頭檔寫 inline function 而增加編譯時間,本人有一點看法,就在此和大家分享。

首先,我們知道

Inline function 的目的是增加執行效率,但一般在 debug 版本是不會被展開的,只有在 Release mode 才會用到。

那麼,在編譯 debug 版本中使用 inline function 只會增加編譯的時間。基於這一點,我現時的”引擎” (不知何時才能算是真正的引擎,可以去除引號)的代碼 layout 就使用 macro 去解決這個問題。所有類別的代碼 layout 分為 3 個檔案: header (.h), inline (.inl) 和 implementation (.cpp)。例如:

繼續閱讀

完成 Win32上的OpenGL/Cg

星期六日都坐在家中做 OpenGL/Cg 的移植,比想像中遇到更多問題,但終於在三月最後一個晚上完成。這裡做一個簡單的回顧,希望大家遇到類似的問題時可以減少脫髮。

編譯期選擇圖像 API

之前曾經寫過一篇《跨平台的圖像渲染引擎》,提及使用 abstract factory pattern 或 conditional compilation (macro) 來為圖像 API 抽像化。後者的優點是效能較高 (不需使用 virtual function call),但缺點是代碼難看。為了改善後者的缺點,我想到了使用 inheritance 去避免在 class 的定義裡寫 macros。舉一個例子就會明白。

首先,利用 #include 後可以是一個 macro 的功能 (Visual C++ 裡只可以是一個 macro identifier,而 gcc 可以 expand macro),把平台相關的 header 和 implementation 檔放在同一個地方:

繼續閱讀

新面貌

終於更換了之前的預設 wordpress template。新的 template 維持簡潔風格,字體應該比之前的較容易閱讀。希望大家喜歡。

另外,從上星期日開始做 Linux porting。在 Vmware 上安裝 Ubuntu 來測試。發覺自己完全忘記了 makefile,中途還想放棄去改用 scons。最後還是繼續 GNU make,終於今晚搞定用 makefile 執行 SWIG,不過有點兒 hard code 成份。明天開始做 OpenGL + Cg。

PS. 荷蘭來的舊朋友在我家住了兩天,因他的來到,我們才找附近的好餐廳,吃了兩晚豐富的晚餐。昨晚玩 Wii Sports 和 Wii Fit 玩到一點鐘。
PPS. 問同事借了 PSP 玩 《無限回廊》。這是創意之作,而且我本身又喜愛 M.C. Escher (荷蘭畫家!)。

實時 Radiosity 系統 Enlighten

今天才第一次看到 Geomerics 的 Enlighten 新示範短片(在 GDC2008 發佈),感覺很震撼。雖然在 Radiosity 技術方面和他們一年前的 Tech Demo 的分別可能不大,但結合了 HDR、SSAO 等技術、展示了一些使用者介面即時調效多個光源的設定、人物受到間接光源的效果等等,做出來的整體效果完全不一樣。而且,它說明這技術已實際在 PS3 和 Xbox360 上應用 (雖然沒有影片為證),即是它是可以應用在現今的硬件之上,而不是一些只可期待而不能用的技術。

網站裡介紹了 Enlighten 的工作模式:

  1. 場境需要作一些 pre-processing,但只需要 gemoetry 資料,而不需要 texture、material、lighting 等資料。這和 Precomputed Radiance Transfer (PRT) 的需求一樣。
  2. 使用者的引擎要把場境的 Local Illumination 渲染至 texture space ,交由 Enlighten 計算 Radiosity。
  3. 結合 Radiosity 和 Local Illumination。

使用這種工作模式對美工特別有幫助,因為美工可以即時微調光照效果,而不需使用 Global Illumination 的 Renderer 去花幾十分鐘甚至幾小時去渲染一些只是靜態的 Light Map。我相信除了遊戲之外,電腦動畫及電影特效都應該可以應用這種技術。

要追技術感覺是越來越難。不過我要提醒自己,不要只追求個別的技術,現時需要的應該是做整個遊戲的經驗,gameplay 和相關的工具是我最弱的。

其他類似的技術:

《修改代碼的藝術》

自從看見書評有關一本名為《修改代碼的藝術》(Working Effectively with Legacy Code, by Michael C. Feathers)的書,感覺是工作上很有需要,就急忙走上 amazon訂了這個內地中譯本。昨天收到並讀了幾章,先說一些表面的,看完後再寫讀後感吧。

如同本書的介紹說:

如果不積極地修改、挽救、隨著時間流逝,所有軟件都會不可避免地漸漸變得複雜、難以理解,最終腐化、變質。因此,理解並修改已經寫好的代碼,是每一位程序員每天都要面對的工作,也是開發程序新特性的基楚。

這些話語都像在對我說的。工作上,每天也要去修改一個很大的 code base,看 source code 好像 reverse-engineering 一樣,看到一些代碼甚至會感到沮喪。或許這也是許多這行業的人的經驗吧,可是我卻是非常缺乏這種經驗,因為以前的我比較多是維護自己設計軟件,比較少去修改別人的軟件。

遺留代碼一般所想就是沒有人維護、時代久遠、甚至是很爛的代碼。但作者對遺留代碼的定義和一般所想的很不同:

對我來說,遺留代碼就是沒有編寫相應測試的代碼。

這不是對遺留代碼字面的解釋,而是一個深切的體會。從樂觀的角度看,這定義引申,遺留代碼並不是無藥可救的東西,只是沒有測試程式而已,只要耐心加入測試機制,就可以慢慢地挽救。

作者提供了一連串的修改程式技術,這些技術沒有正統的名稱,所以每個章節的名稱也很長,例如「第22章 要修改一個巨型方法,郤沒法為它編寫測試」。從目錄看到這章的名稱,又令我回想一個月前用了一整天去理解一個幾千行的函數的遭遇。但是,很諷刺地,在這一部份的最後來一章又叫「第24章 當你感到絕望時」。昨天面對代碼而感到無助時,便立刻看了這一章,頓時覺得,我還未到絕望的境地,心態一轉,難題也解決了。

今天讀到 Fake Object 和 Mock Object,開始明白 Edwin 做的 AMOP 有幾偉大。

要寫漂亮的代碼是以往的一個目標,今天覺得,要寫不變成遺留代碼的代碼,是更重要的。如何在遊戲編程中實踐編寫測試是我今天的疑問 (對於圖像、互動的測試等…..),希望看畢本書後有新的體會,再與大家分享。

Home

Search
Feeds
Meta

Return to page top