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