摘要: 這個例程中我們將學習怎么使用irrlicht中的分屏(比如在賽車類游戲中）{
我們將創建一個被分為4個部分的視口，有3個固定攝相機和一個用戶可以控制的攝相機好，讓們從頭文件開始吧（我想沒有再多說的必要了）
閱讀全文
摘要: 理清一個引擎，不得不先理清它的層次結構，進而理清渲染流程。 本文給出了鬼火引擎中的設備抽象層，有助于對鬼火引擎源碼的快速閱讀
閱讀全文
摘要: 游戲開發中，計算機圖形學是必不可少的東西。許多人也是從接觸圖形開始而進入游戲行業的。3D管線導論這本書詮釋了3D管線的細節。為大家解開了縈繞已久的迷團。
閱讀全文
http://www.guibian.com/article.asp?id=87我在這個行業呆了快2年半了。其中輾轉過2，3個公司，有業內很大的知名公司，也有業內名不見經傳的小公司。從業過程中也認識了不少在各大公司的同行。如果不出意外的話，基本上我不打算繼續在這個行業呆下去了，盡管我現在收入頗豐，但是我覺得這不是我想要的生活方式。
那么我們來討論下目前整個國內游戲行業的狀況。我覺得是非常糟糕的。據我估算，有一定游戲制作水平的人員應該不到萬分之一，而這當中很多老人已經從事行政工作，另外一些雖然在技術的一線，但是由于年長或者其他原因，工作時長較少，也不足以面對紛繁復雜的行業進步。當然更重要的原因是以下幾個方面：
1.策劃：估計策劃是整個目前游戲行業里最受非議的職業了，策劃之所以受到如此待遇，我想差不多兩個方面原因，主觀上，是從業人員素質低下，游戲行業的迅速發展人員奇缺，導致迅速擴張后無法控制人員素質。大部分策劃在我看來不是不適合做這項工作，而根本上就不適合工作。他們自以為比別人多玩了幾個游戲就知道什么策劃，簡直的是莫大的笑話。極其混亂的思維，缺乏理性的規劃，以及少的可憐的經驗，加上不努力工作幾乎已經導致策劃成為整個開發的瓶頸了。
由于策劃的水平過低，導致程序必須關注他們本來不熟悉的系統及邏輯，而把大部分時間浪費在邏輯上。策劃的水平也直接影響到美術制作過程中對數據，質量的規劃，最終多次返工。（后面我會說好的團隊的樣子）
當然沒有經驗也有很多客觀因素，在目前中國這個急功近利的社會。策劃從一開始就沒有辦法按照自己的思路來規劃游戲本身，他們只能東抄西抄。形成一種惡性循環。不要忘記宮本茂也不是一天練成的，他也是經歷了無數的失敗以后才創造了馬里奧，如果只是一味的模仿，怎么會有進步？
2.其他兩個職業，程序與美術。游戲的高速發展，也把兩個本不值得關注的職業推上社會的舞臺。
美術說白了就是一群成績差的孩子為自己找一個出路，盡管美術是一個我覺得很高尚的職業，但你不得不承認在中國這種缺乏人文精神，藝術氣息的國家里，美術是不受尊重的。當然我們并不缺乏熱愛美術的人，但是如果一個人真的熱愛美術，我想他是決計不會再游戲行業呆多久的，因為這里只會扼殺美術。游戲行業里美術如果細分，至少可以分為藝術與技術兩個部分，技術不用說，從我工作至今，認識的美術中技術很強的少之又少，因為要讓一個畫畫的人去了解圖形顯卡是件很困難的事情。藝術呢？也沒好到哪里去，原因我剛才已經分析過，國外的游戲往往能刺激美術這項工作的發展，而在國內，美術越來越往民工發展。
程序也沒好到哪里去，游戲行業的高薪水吸引很多原先并不被看好的IT界“精英”們擠到游戲界，另外越來越多的水品差的新人也選擇把游戲作為走入社會的第一份職業。結果就是代碼質量低下，層次結構亂。而且為了應付項目進度，不用談架構了，連代碼都是湊出來的。因為邏輯系統復雜，需求不斷再變，所以程序就可以冠冕的說不容易設計好的架構，在我看來這是非?；熨~的說法。好的程序不會因為項目的大小，而做出好賴差別很大的設計。做不出好設計的程序員，我想不僅是項目設計不好，也許就連一個類他們也抽象不出來，這是程序水平低，而不是游戲程序設計水平低的問題。
3.公司大小的矛盾。小的創業公司，有激情卻沒有好的技術人員，大的成熟公司，有好的技術人員卻沒有激情。我曾經呆過小公司，在小點的公司。技術是非常缺乏的，往往只有一個稍微有經驗的從業人員，但是由于沒有系統的規范，沒有完整的流程，大家幾乎都在不斷的嘗試著失敗，直到磨平最初的激情與意志。
當然大公司在我看來更糟糕，雖然有重金請來技術人員，但是沒有激情。復雜的領導裙帶關系，散漫的工作態度是大公司最大的弊病。由于領導不懂開發環節，而對開發人員的過度干涉，導致項目進度遲緩設置流產。下屬員工不思進取，每天消磨時間，領導在的時候做做工作，不在的時候各自活動，聊天的聊天，上SNS的上SNS，泡論壇的泡論壇。各級主管也有很大的問題，國內目前主管的水平在國外也頂多就是個一線工作的新人，所以主管如果不努力提高自己的水準勢必導致游戲制作水品底下。但是很不幸，我在各個公司看到的結果就是，各級主管毫無激情，固守著自己可憐的一點點過時的技術。美術主管不懂圖形，甚至對制作非常放松，造成最終難看的效果，過度的浪費與消耗。我聽得最多的一句話就是，無數美術抱怨引擎的局限性，我想說的是，不管多么不好的引擎都不會給游戲畫面本身帶來多大的限制，如果做不好只是自己的水平問題跟引擎毫無關系。程序主管就更可悲了，我認識的有的人當中只是會寫幾句if ... else ... for循環，不知道什么事模板，甚至搞不清楚繼承與虛函數。他們只是固守著陳舊的經驗或者依賴于早年工作遺留下來的幾個庫維系著自己可憐的位置。
4.在中國這個畸形的社會，游戲界基本靠的是市場運作，而不是產品本身。所以不需要高品質的游戲，也就使開發人員自暴自棄。進而越來越差。我認為沒有了激情的公司勢必不會在歷史的長河中存在太久。試想卡馬克這樣的天才還要一天努力工作16個小時，我們有怎么有可能超過別人？去看看暴雪，去看看Epic總部，那里人的工作狀態，再看看我們，差距只會越拉越大。每一個游戲工作者都可以捫心自問，我是否真的熱愛游戲這項事業，而不是熱愛那可憐的幾千塊錢或上萬塊錢的月收入。我是否真的每天為只付出了我最大的努力，而不是混混日子得過且過，固守著自己貌似安逸的生活。我身邊的每一個人好像都無所適從等待著公司上市這樣的奇跡發生，我覺得真是可笑和可悲。
5.附上一個我心里的優秀團隊的樣子：
首先，要有資深的從業人員討論定義所有的制作規范，開發流程，項目進度等。
其次需要一個優秀的開發團隊，團員每個人無論是否有經驗，至少要有激情，他們愿意付出比別多出多倍的時間精力來投入到項目中去，在游戲邏輯方面我認為并沒有太多技術障礙，頭腦清楚，肯于思考的策劃都可以往邏輯程序員方面發展。而從事圖形相關的程序卻需要比較專業的基礎知識。游戲開發不是一個輕松的工作，至少比起IT同行業，我認為要付出更多的努力。
策劃人員要對游戲內容有精確的定義，框架，大方向，游戲邏輯都要事先確定的非常清晰。保證程序員不用浪費太多的時間去關注復雜的游戲邏輯，而把時間花費在游戲架構設計本身，以及開發更多更便捷的工作，幫助策劃和美術提高工作效率。策劃人員同時也要協同程序人員幫助美術制作者，用最好的方式把效果在游戲中發揮到最大化。當然管理人員要安排好測試人員，版本構建人員的隨時跟蹤，以保證項目穩定健壯的發展。
成員之間要相互信任，互相敞開心扉，承認自己的確認和弱點。針對不通的意見要多辯論，不要做一些無關痛癢的討論。積極投入到決策和行動計劃中去，不要事不關己高高掛起，每個人都應該為游戲本身付出更多，改進更多。對影響工作計劃的行為負責，不要推卸責任，項目中誰都可能犯錯誤，但是自己一定要通過努力彌補過來，不要覺得由于其他的人問題導致自己的怎么怎么樣。要把重點放在集體成績上，不要以為自己的分內工作完成了就萬事大吉了。
也許你覺得我的要求很高，也許是你不熱愛這項工作吧。
材質，這個詞有各行各業都有自己的解釋。
美工把物體貼圖和物體顏色，高光等統稱為材質。D3D和OPENGL這樣的圖形接口則把物體表面貼圖單獨叫做紋理，而把漫反射，高光等叫做材質。
而在游戲引擎或圖形引擎中提到的材質，則與此不同。 引擎中提到的材質不僅上面的的內容。 引擎中所謂的材質，是指物體在渲染時一系列的狀態控制。 如，ALPHA混合開關以及ALPHA混合因子、紋理過慮方式，紋理通道狀態、紋理矩陣、裁剪模式等，在D3D中，就是SetRenderState,SetTextureStageState,SetSamplerStateState等所控制的。在OPENGL中，則大多數由glEnable所控制。
我們所提到的材質系統，則是以此為基礎展開的。 上面提到的這些因子，組成了我們的材質。 也是我們在渲染一個物體的時候，提交到設備的狀態控制值。 一個物體的一次渲染，我們稱作一個PASS。于是我們順其自然地將這個渲染時的材質控制的最小單位命名為Pass,則：
struct TextureState
{
void* Texture;
int ColorOp;
int ColorAgr1;
int ColorAgr2;
int AlphaOp;
int AlphaAgr1;
int AlphaAgr2;
.....//更多內容
};
class CPass
{
CColor mAmbient;
CColor mDiffuse;
....更多內容
bool mAlphaEnable;
int mScrBlend;
int mDstBlend;
int mCullMode;
TextureState[4] mTextureStates;
...更多內容
};
當我們渲染一個物體的時候，只需要將這個類里面的狀態應用到設備，即可完成對物體的繪制。
材質系統的基本內容就是這些，這也是最容易做到的事情。
但是，我們都知道，像D3D或OPENGL這樣的圖形接口每設置一次GPU狀態的時候，都會有一定的開銷（通過查看相關文檔可以看到某些函數的具體開銷值）。而為了保證我們的渲染流暢，我們不得不減少這樣的開銷。
很自然地，我們會想到，盡量減少切換。而如何減少切換呢。我們可以記錄下自己的硬件狀態，在設置下一個的時候，先判斷當前硬件狀態是否相同，如果相同。則不用再設置。 雖然某些圖形接口在其層底做了類似的功能。但我們外部判斷一下，也未嘗不可。從D3D上來講，外部判斷比讓其內部判斷效率更佳。需要注意的是，由于我們在自己的程序里做了相同判斷。因此，當有另一個程序也修改設備狀態的時候，就會產生意想不到的效果。所以，我們應該適當的查詢一下設備狀態，并更新自己的狀態記錄表。至于這個查詢間隔，就要根據自己的實際情況來測試了。
通過記錄狀態的方法來提升的效率是很不明顯的，因此，我們需要對材質進行排序，至于怎么排序，這算法上的問題，在此先不作過多解釋。 總之，我們將相似的材質排在一起。由于材質很相似，繪完一個再繪下一個的時候，減少了切換，從而大大提升了效率。
既然已經是涉及到設備了，我們總得考慮一下設備問題。 如果設備不支持我們當前給定的材質狀態，怎么辦？ 返回FALSE不渲染。還是讓程序DOWN掉？ 對于一些重要的性能，設備不支持讓程序DOWN掉是最好的做法，但是，對于像紋理混合通道不足的情況，讓其DOWN掉就顯得劃不來了。畢竟我們設計的游戲程序是想讓更多的玩家能玩不是？ 這樣就會涉及到PASS的拆分問題。
對于PASS的拆分，OGRE已經做得很好了。根據用戶的設備性能，如果不滿足，就一直拆分，拆到用戶滿足為止，最后讓一個物體渲染多次，來實現多個紋理通道混合的效果。 而多PASS則是在渲染的時候不得不考慮的地方，畢竟有些物殊效果非得用多PASS不可。
對于多PASS的設計，我們可以參考OGRE的材質方法或是D3DX的效果框架。我們把完成一個最終效果的方案稱作一個渲染技術 Technique ，一個技術可由多個Pass來完成。
class Technique
{
...更多內容
vector<CPass*> mPasses;
};
這樣就滿足了我們的需求。 對于同一種效果，我們可以提供多種Technique供程序選擇。 而這個選擇的條件則可以是根據硬件性能，或是玩家手動選擇的配置來實現。
最后結構如下：
class CMaterial
{
public:
...更多內容
vector<CTechnique*> mRenderTechs
};
亂七八糟地說了一通，希望沒暈死人?。。?/p>