其他

做網路遊戲的都會遇到圓形小地圖問題,網上也有很多相關討論的文章,但是都多多少少有些問題.其實,這個問題並不難,只是很多人總是把他和CEGUI結合在一起,往CEGUI混合方向去考慮,自己搞難了自己 我們反過來從需要考慮, 1。我們每次更新需要的只是1張合成好的正方形圖片,正方形圖片中間的圓形是小地圖內容,周圍是alpha透明的, 2。這個圖片可以用小地圖和一個alpha的遮罩合成.遮罩中間圓形像素1 1 1 1 ,周圍 0 0 0 0 3。我們需要做的的只是怎麼合成這個圖片而已....怎麼合成..

這幾日事情比較多，有文曾問，你能控制的代碼量是多少，經此一役，發現並不多，大約同時能思考進去的功能數量就在數個以內，超過十個就肯定要出問題了。腦子裡太多的想法，到最後就是左支右絀，白白耗盡精力。做室外情境時，遇到的最大問題就是太多的功能要去實現了，到最後手忙腳亂，反倒不如攻其一來得實在。真正用心專攻紋理混合之後，只三天就改完了原來一塌糊塗的東西，第一天資料來源，第二天資料群組織和Shader，第三天修改。真是痛惜前段日子浪費的那麼多時間啊！旁的不多說了。目前使用的混合方案是：每個Block最大4

 天龍X部粒子系統在OGRE的基礎上通過外掛程式形式自訂了一些粒子系統: 添加發射器1個PolarEmitter 添加效果器6個ColourFadingMeshAnimationAffectorMeshRotatorMovementRevolutionScaleInterpolator 添加的Renderer

崩潰中，終於翻譯完了，不管到底翻譯得如何。很久沒有這樣熬通宵來翻譯文章的了，天天被外包折騰，夜裡唯有的時間只能用來做自己想做的東西。我應該是屬於晝伏夜出動物，這樣才能滿足自己的喜好和習性吧？由於機緣的巧合，去年開始，自從在工作中被迫接觸到這個技術之後，就不斷被Unreal的Deferred

有朋友說我的源碼有些地方填充不到...四向聯通是這樣的,改成八向就可以了 /*** 種子填充演算法,八向連通,用來產生水平面* @param fillPointY 填充點的y座標*/void ObjectLiquid::boundaryFill4(int x, int z, Real fillPointY){int index = x + z*(mXSize+1);Real currentPiontY = mHeightMapData[index]; // 得到當前點的高度//

終於喝了傳說中的依雲幾年前在超市，我看到過一個礦泉水，標價8元/小瓶，沒見過世面的土老冒我被嚇壞了，一小瓶水，居然賣這麼貴，於是感歎用錢人的幸福，和我沒錢的痛苦，心理暗道“總有一天我也要買2瓶，喝一瓶，倒一瓶”，然後轉身拿起一瓶1.5元的水猛灌。周末，老婆的同學攜老公來玩，吃飯後無事，跑卡拉OK房K歌，不一會，有人抱來飲料和水，正口渴，抓起一瓶就喝，也沒覺得如何，結果回家老婆說，你喝的那小瓶水16塊呢。我猛地想起，莫非這就是傳說中的依雲礦泉水？一問，果然就是，哈哈，無意之間，當年的夢想就圓了一半

 有的地圖不是tile的整數倍,有的地圖沒有WCollision檔案,有的地圖有centre等有的地圖沒有光照圖等等 比如武當的地圖不是tile的整數倍,那麼就需要調整tile大小,其實只需要稍微改動源碼沒有經過最佳化的,比如不需要更改的函數參數可以全部改成const引用,提高效率的自己去最佳化了,  void TLBBTerrain::createTerrain(){// 產生材質,

為了方便查看,添加了一些菜單功能  實現起來也很簡單,點擊菜單就是bool值的轉換而已,然後在frameStarted裡面更新:1, 做一個全域的靜態類來儲存這些全域的bool值變數,因為這些變數要跨幾個檔案用到,需要全域的,2, 自己添加ON_COMMAND訊息,並實現訊息響應函數,函數就是bool值的轉換而已3, 添加ON_UPDATE_COMMAND_UI訊息,並實現訊息響應函數,處理菜單的狀態,主要用來顯示菜單的對勾4,

用其他大俠資源提取工具,可以提取到情境資料,有些資料格式是XML檔案,很容易看懂,而有些就不能直接開啟,要自己提取資料了,比如GridInfo和HeightMap檔案,一個是網格檔案,一個是高度圖檔案,十分重要,我準備先研究這2個傢伙. 先說網格檔案:找到網上大俠的一些研究資料:http://www.mobilegamebase.com/blog/article.asp?id=17不過，此文中有點筆誤的地方，就是那個nFirstLayerOP的位標記的描述有點錯誤，正確的應該如下：//

最近，隨著外包告一段落，開始整理和重構GC了，順手整理一下GC的MRT。之前沒有認真讀完的星際2的白皮書，這次至少是把MRT部分和Shadow部分讀了一下。先說MRT吧：星際2的MRT大約如下配置： 具體就不解釋了，看樣子，為了保證精度，每個MRT應該都是64-bit的，0、2、3三個MRT儲存表面顏色資訊，1用來儲存對於DS而言最重要的Normal

以前遊戲水面的做法都是用很多張圖的序列幀實現的紋理動畫，這種固定渲染管線的方式，在最低畫質的時候採用特別好，但是對於更進階別的畫質，就應該採用更好效果的水面。水面渲染，Ogre有個外掛程式叫Hydrax，效果很不錯，但是效率也低的很，沒任何實用價值。只好自己做一個。一個漂亮3D遊戲水面的，一般有水波類比，bump mapping，倒影，折射，菲捏爾效果，水下效果等，我準備做一些取捨，實現高效率。1）只保留倒影，去掉折射，菲捏爾效果，水下效果，因為2.5D遊戲，視角比較固定，也不需要深入到水下。2

dbghelp這個方案比較複雜，速度也比較慢，不過用在Trace的場合也不算太糟糕。原理是，dbghelp.lib、dbghelp.h提供了一大堆擷取當前調用棧資訊（ESP、EBP），並通過這些調用棧，配合上相應模組的pdb檔案，得出當前的調用模組（dll）、調用函數、調用行和指令。具體的原理就不再廢話了，網上dbghelp的使用方面的文檔也很多，貼幾個參考：HOWTO: Dump Call Stack一個調試器的實現（五）偵錯符號使用DbgHelp擷取函數呼叫堆疊之inline

只能說，現在主流遊戲地形每層之間的混合方式，都是採用Slatting技術，每層地表之間的alpha混合，都是美術在編輯器刷出來的。而老的遊戲，比如天龍，還沿用魔獸3那種拼接的地形，比圖土地和草地的融合都是做圖做好的，而不是即時刷出來的，導致做不了漂亮好看隨心所欲的野外情境地表。暢遊以這套地形出來的所有遊戲，野外地表都有這個問題，反正不好看，而且這麼多年也沒人去修改一下。實現思路也很簡單，以2層地表混合為例子，用一張大圖的alpha通道儲存整個地形2層之間的alpha值，而RGB通道可以做顏色貼圖

        這個心結的初期表現可以追溯到我4歲讀幼兒園時發生的一件事。有一天，我跟幾個小女孩一起玩，其中有一個突然提議說大家一起扮香港小姐。有個女孩就搶著說：     “我做李嘉欣（那年可能就是88年）！”      “不行，我做！我最漂亮！”另一個女孩高聲嚷著。      “不對！我做！”“我來做！”……       這時候只有我站在一旁愣著看她們在吵。雖然那時候心裡真的很想自己是最漂亮的那個，但我話到嘴邊又不敢說。我不明白為什麼當時我不敢跟她們爭。      

這是我以前升級Ogre引擎，實現的一個方案，願意拿出來分享下經驗。每個精通Ogre的程式員，都會對Ogre內建的陰影方案感到失望，不管是模板陰影，還是投影陰影，都是固定渲染管線的陰影，效果都不好。暢遊《天龍八部》都升級到3了，還採用以前的陰影方案，說明要找個理想的方案替換以前的真是很難。天龍的方案是，人物用模板陰影，情境用靜態烘培的陰影貼圖貼地形上。效果一般般，這是以前很多遊戲的做法。由於模板陰影是基於模型頂點的，沒法支援alpha test。那麼樹葉這種帶有alpha

針對的系統是CentOS 5.4 , 顯卡型號為：NVIDIA GeForce 9800 GT 從http://www.nvidia.cn/Download/index.aspx?lang=cn找到驅動並下載  安裝時一直報類似下面的錯：Using: nvidia-installer ncurses user interface-> Tagging shared libraries with chcon -t textrel_shlib_t.-> License accepted.-

在過去的一段時間內，我也實現了幾篇關於立體匹配的學術論文，程式最終的顯示效果卻遠不如論文中呈現的效果，可是自己編寫的程式是嚴格按照論文中的步驟和參數設定的，為什嗎？經過上網尋找資料和閱讀論文，發現了其中一個原因。如果程式真沒問題，可能是論文中沒有介紹額外的處理步驟，即一些後續處理步驟（post-processing），比如左右一致性檢測（left-right

改進粒子系統-粒子拖尾最近美術要求粒子可以拖尾，實作類別似於《鬼武者》中的吸魂、煙花等效果。大概思路是將粒子經過的路徑記錄下來，形成一條面向攝像機的三角鏈。：參考：Ogre的BillboardChain, RibbonTrailTODO：1，粒子消失時不自然，應該是粒子等待拖尾消失後再消失。              2，支援設定1D，2D紋理。           (已解決）改進:１, 不再將2D粒子做為一種渲染器,而是做為粒子的一個屬性.

 for each face....  FaceEx *pFaceEx = pGameMesh->GetFace(faceId); // 得到位置 int vertexId = pFaceEx->vert[faceVertexId]; Point3 vertex; if( pGameMesh->GetVertex(vertexId, vertex) )  pVertexData->m_position = vertex; // 得到法向量 int normId =

big endian和little endian　　big endian和little endian是CPU處理多位元組數的不同方式。例如“漢”字的Unicode編碼是6C49。那麼寫到檔案裡時，究竟是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是big endian。還是將49寫在前面，就是little