摘要: 本篇是創建游戲內核（1）【C風格版】的續篇，關于該內核的細節說明請參考創建游戲內核（2）。
閱讀全文
摘要: 該版本根據接口與實現分離版改的，因為接口與實現分離寫起來太煩瑣，所以直接使用結構體。由于結構體的數據成員可以直接訪問，可以減少編寫大量的接口函數，同時對于簡單的數據結構采用函數封裝，只對復雜的功能模塊采用結構體封裝，減少抽象對象的使用以最大限度增加代碼的透明度。
閱讀全文
摘要: 在1998年的元旦，Bjarne Stroustrup（C++之父）接受了IEEE《計算機》雜志記者的專訪。編輯很自然的認為他會對于過去七年來使用他創建的語言進行面對對象設計做一個歷史性的回顧。而在這個專訪中，記者獲得了更有價值的新聞，但是最后編輯決定為了整個IT產業，這個稿子不能發表，但是就像其它被砍掉的新聞，往往還是弄得路人皆知的。
這一篇是當時專訪的完全拷貝，沒有被編輯、刪改或者做過什么潤色處理，也沒有發布過，可能看起來不像常見的雜志文章，但這是實情。
你會發現真正引人入勝的地方... ...
閱讀全文
摘要: 3D圖形引擎【OO改良版】的代碼以創建游戲內核【OO改良版】中編寫的代碼為基礎進行開發，關于該引擎的細節說明請參閱創建3D圖形引擎。
閱讀全文
摘要: 使用單一的網格模型雖然可以同時渲染整個層次，但卻意味著那些沒有被看到的部分在通過渲染管道時會被裁剪掉，也就是說這樣做會浪費時間。不要沮喪，因為使用一個單獨的網格模型進行層次的渲染仍然有一些非常好的方法。比如說，在游戲世界中包括了單獨的地牢，每個地牢包含不同的房間，所有的房間通過走廊連接到一起。其實，每個房間和走廊就是一個單獨的網格模型，所要做的就是在游戲的處理過程中加載以及釋放那些代表地牢房間的網格模型。
閱讀全文
摘要: 本篇是創建3D圖形引擎（3）【OO改良版】的續篇，以創建游戲內核【OO改良版】中編寫的代碼為基礎進行開發，細節說明請參閱創建3D圖形引擎（4）。
閱讀全文
摘要: 本篇是創建3D圖形引擎（2）【OO改良版】的續篇，以創建游戲內核【OO改良版】中編寫的代碼為基礎進行開發，細節說明請參閱創建3D圖形引擎（3）。
閱讀全文
摘要: 盲目地繪制成千的物體而沒有執行任何的剪切，是導致在圖形-渲染通道中時間延遲的一個主要原因。需要再次使用視錐以快速確定哪些物體位于視野中，為了確定哪些物體是可見的，可將每個三維物體包圍到一個可見的球體中，稱之為框界球體（bounding sphere）。
下圖演示了框界球體和視錐的運用，它展示了一個場景，其中有三個物體和一個視錐，每個網格模型都有一個可見的框界球體圍繞著它。當一個球體位于構成視錐的6個平面前時，它就被認為是可見的。可以看出僅兩個位于視錐中的物體是可見的，而另一個物體完全位于視錐外，繪制時能完全跳過那個位于視錐之外的物體。為了實現這一點，必須計算每個物體的框界球體，然后檢測球體是否位于視錐之內。
閱讀全文
摘要: 在每幀中繪制所有的多邊形是非常低效的，為了提高處理的速度，可以僅渲染那些位于視野內的多邊形，同時應避免掃描場景中的每個多邊形來確定哪些多邊形是可見的。如果不每幀進行搜索，又如何知道哪些多邊形是位于視野內呢？解決的方法就是將一個三維模型分解為一些較小的塊（稱為節點nodes），其容納較少的多邊形。然后將節點排列到一個特定的結構中（一棵樹），以便進行快速搜索，并確定哪個節點是可見的，然后渲染這些可見的節點，通過使用視錐，可以找出哪些節點是可見的。取代搜索數千個多邊形，通過搜索一個小小的節點集合，就能決定怎樣進行繪制。節點樹引擎適用于任何的網格模型，并將它拆分為節點，以便快速渲染網格模型（網格模型代表了游戲的層次）。
閱讀全文
摘要: Javascript是世界上最受誤解的語言，其實C++何嘗不是。坊間流傳的錯誤的C++學習方法一抓就是一大把。我自己在學習C++的過程中也走了許多彎路，浪費了不少時間。
為什么會存在這么多錯誤認識？原因主要有三個，一是C++語言的細節太多。二是一些著名的C++書籍總在（不管有意還是無意）暗示語言細節的重要性和有趣。三是現代C++庫的開發哲學必須用到一些犄角旮旯的語言細節（但注意，是庫設計，不是日常編程）。這些共同塑造了C++社群的整體心態和哲學。
閱讀全文