其他

把OGRE和bullet的地形整合在一起比預想中的麻煩。主要是兩個問題：通過HeightField產生三角形網格的方式不一樣，以及HeightFiled定址方式不同（OGRE轉換成float數組後，以坐下角為(0,0)點，而bullet的btHeightfieldTerrainShape類是左上方）。好在需要改動的地方在btHeightfieldTerrainShape都是虛函數，所以可以通過繼承來解決（看來作者已經預料到這些問題，不過注釋很少，很多東西需要看源碼才能弄清楚）。以下是改動的地方：

X檔案的使用（完整） [轉]這兩天精神不太好，沒寫，先轉一篇同樣內容的來湊數吧[Copy to clipboard]CODE:    有很多朋友也許想更加瞭解X檔案，正好，本文將全面的介紹X檔案的使用。我想這是一篇純技術性的文檔，我就不加以詩篇歌頌潤色了。相信讀我的文章，就像啃牙籤；）好了，我們板起面孔。首先給你一個完整的印象----傳說中的X檔案：xof 0302txt 0032 template Header {<3D82AB43-62DA-11cf-AB39-0020AF71E433

上次用解析字串的方式來列舉目錄和檔案, 速度太慢尤其像Common.mpq這樣一個MPQ的listfile就幾兆的情況下, 速度簡直不能忍受再想想ZipFileSystem中的FileEntry和DirEntry, 我想它們是用來快取檔案分類樹的吧在記憶體中進行尋找肯定比讀檔案快, 更不用說去解析字串了還是加入進去好了與Zip不同的是, 我沒有把檔案一次性讀入記憶體. 因為mpq本身就支援Seek, 不需要讀到記憶體去類比. 如果想映射到記憶體進行快速存取,

在http://www.scottberkun.com看到的另一篇，蠻有意思。(話說這個網站用的表徵圖是其作者名的簡寫S*B...)   Asshole driven developmentThe software industry might be the world’s greatest breeding ground for new systems of management. From Agile, to Extreme Programming , to Test Driven

今天粗略測試了一下boost::bind的效能，得出以下幾個猜測(僅限於gcc，windows下未測試)：boost::function內部預留了(sizeof(成員函數指標) + sizeof(指標))的空間，所以如果bind的參數佔用空間小，則會使用placement new的方式，不會涉及動態記憶體分配。典型的情況如boost::bind(成員函數指標, 對象指標)，或者全域函數指標加少量參數的情況。這種實現方式類似fast

天啊, 自己解析(listfile)本身就是一個錯誤!因為StormLib在開啟MPQ檔案時就已經自己解析過了, 沒必要多此一舉!而且, 雖然自己緩衝一下檔案樹會加快尋找和枚舉的速度, 但是, 從字串構造這個棵樹的時間太長了~~~這就導致了一個很嚴重的問題: 啟動速度慢.......對於檔案樹, 遊戲沒有什麼用, 因為遊戲讀檔案時根本不管是什麼目錄, 你可以把目錄也看是檔案名稱的一部分換句話說, MPQ包雷根本就沒有目錄的概念!而對於編輯器等需要列舉檔案/資料夾清單的場合,

忙活了一個多星期，差不多把基於TCP的高並發串連網路架構測試穩定了。目的：利用多線程把網路連接及資料包壓縮/解壓、加密/解密等等耗時的操作分流（asio對這些沒有原生的支援），順帶提供線程池架構。只對遊戲邏輯層暴露出單線程的外觀，隔離底層多線程的複雜度。結構如（未遵循什麼標準，將就著看吧）： TCPSessionHandler：暴露給邏輯層的類，內部負責通過TCPIOThreadManager跟掛載於某個線程的TCPSession進行互動，對上層屏蔽多線程細節。聲明如下：class

在邊緣高亮效果中我提到過兩種方法, 各有優缺點吧 映像空間域的邊緣檢測效果比較好, 中間沒有多餘的線條. 缺點是PS中計算比較慢第二種把模型"放大"(其實是變胖)的做法, 可以在VS中完成, 不需要額外的RenderTarget, 適合低端顯卡使用, 適應性好. 不如果模型法線資訊不對的話, 會造成畫面錯亂. 實際使用時可以根據W值(不用Z深度)來畫出遠近粗細一樣的線條 這次提到的基於法線的方法, 其實跟2D的空間域邊緣檢測很相似, 如果要求結果是繪製物體的線條圖而不僅僅是一個邊緣輪廓時,

.BLP files are texture files used in games made by Blizzard Entertainment, also used in other games like Neverwinter Nights. While Blizzard provides an Interface AddOn Kit for extracting the user interface files from the World of Warcraft .MPQs,

Attr命名空間下實現了Mangalore裡的動態屬性. 屬性是編譯期間型別安全的key/value對, 這是資料庫(database)子系統的基礎. , AttrId相於屬性類型, 而AttributeDefinition是屬性類型的定義, 其中包含了屬性名稱, 屬性的四位元組碼, 實值型別和訪問類型(讀/寫). 也就是說, AttrId是AttributeDefinition的執行個體.實際使用時我們關心的是Attribute類. 那麼使用Attribute有什麼好處呢?

  BNF is an acronym for "Backus Naur Form". John Backus andPeter Naur introduced for the first time a formal notationto describe the syntax of a given language (This was for the descriptionof the ALGOL 60  programming language, see [Naur 60]). To be

基於時間的動作時間單位：ms速度慢的電腦可以通過丟幀來保證動畫的速度在Windows中讀取時間用timeGetTime()函數，詳見MSDN可以在函數的開頭用靜態變數來儲存時間：void FrameUpdate(){  static DWORD LastTime = timeGetTime();時間相關的動畫記錄動畫的開始時間，然後儲存每一幀相對開始時間的位移量主要畫面格的格式，包括時間和變換矩陣：typedef struct sKeyframe {      DWORD Time;      

官方文檔參見:http://klayge.sourceforge.net/html/font_in_klayge.html這裡只是一些測試看了龔敏敏寫的文檔, 覺得這種方式很意思, 就拿來玩玩.因為中文字型的渲染在3D程式中確實是個問題, 尤其是字型大小不固定時, 放縮會出現走樣.KlayGE的方法是一種用點陣圖類比向量圖的方案, 把計算過程放在字型產生時, 而運行時的繪製相對常規方法來說消耗很小. KFontGen目前好像有問題, 產生過程中會由於超出32位所能定址的最大記憶體而報錯退出.

最近渲染器終於穩定下來了, 效果也做得差不多了, 於是做一下總結當初為了追求進度和效果, 直接就是採用最暴力的A16R16G16B16F x 3的G-Buffer:COLOR0Normal.xNormal.yNormal.zDepthCOLOR1Diffuse.rDiffuse.gDiffuse.b COLOR2Specular.rSpecular.gSpecularbSpecular  Glossy可以說沒有什麼特殊的, 效果是出來了, 效能很是問題所以想投入實際使用還是要最佳化一下效能,

asio中socket通常的用法如class Session { public: void HandleRead(const boost::system::error_code& error, size_t bytes_transferred) { if (error) { delete this; return; } ... } void Read() {

原文連結:http://blog.oasisfeng.com/2006/10/19/full-cjk-unicode-range/ 註：在絕大多數應用場合中，我們可以僅用（1）、（2）、（3）、（4）、（5）的集合作為CJK判斷的依據。1）標準CJK文字http://www.unicode.org/Public/UNIDATA/Unihan.htmlCode point rangeBlock nameReleaseU+3400..U+4DB5CJK Unified Ideographs

範例程式碼見http://eddyserver.googlecode.com/svn/trunk/common/tests/messagetest.cc NetMessage類提供了相容stl的介面，通過boost::iostreams樣本的ContainerDevice可以方便的與boost::iostreams::stream結合起來。而boost::iostreams::stream繼承自std::stream，可以像標準流一樣操作。protobuf提供了序列化到流和從流中還原序列化的介面

 現在我們的工具全是MFC的, 維護起來那叫一個鬱悶一直在找一個C++中好用的UI庫, 看過Qt(看起來到不錯, 懶得學), wxWidgets(跟MFC一個樣), 剩下的就不說了......前段時間發現了Xtreme ToolkitPro, 裡面那些Samples很強大, 也有過用它來做介面的衝動但是想想, 這東西還是基於MFC, 一樣還是要手動寫........很懷念大學時在C#裡整得那些東西, 做介面超級方便但是, 要在C#裡用C++的東西, 還要中間再加一層, 隔著衣服摸起來怎麼會爽~~

google protobuf訊息序列化後的資料是沒有類型資訊的。而一般網路應用要求序列化後發送到對端，還原出類型，還原序列化，再派發給相應的訊息處理函數。以下代碼簡單實現了自動派發的機制。新增protobuf訊息只要增加一行聲明的代碼和相應的處理函數就可以了。http://eddyserver.googlecode.com/svn/trunk/common/tests/protoserver.cc  #define DECLARE_MESSAGE(x) case k##x##ID: /

    拿到《龍》有半天的時間了，除了工作編寫代碼以外，編譯時間我都在用來看這款期盼已久的網遊。在寫這篇日誌的時候，嘗試了安裝了Windows Live Writer用來嘗試用戶端寫這篇Blog.    1 動態光的處理：    下午晚些時候仔細看了下這個遊戲，開始的時候還以為遊戲中都是靜態光源。沒想到居然還真的用了動態點光源~~~~拿這個情境為例：