其他

記憶體管理C++預設的new效率比較低如果演算法都一樣的話, 好的記憶體管理原則還可以提升一部分效能可以通過預分配來減少動態分配的次數(memory pool)SIMD數學庫有記憶體對齊的需求(XNAMath)Cache MissCPU訪問RAM比較慢, 所以中間有個比較快的CacheCPU訪問資料時會從RAM拷貝一段到Cache, 如果Cache中正好有, 那麼就會比較快的響應; 如果沒有, 就要重新載入另一段到CacheCache Miss沒法避免,

 今天看了看asio的源碼，上一篇的一些疑惑也清楚了。遇到問題果然read the f**king

     定時器管理在MMO伺服器這類需要處理大量事務的系統中，往往是最佳化的熱點。    最簡單的輪詢式定時器的實現如（psudo code）：class Player{public:void loop(){if (timer.check()){//do something;}//other timer ...}private:Timer timer;}void main(){while (true){foreach player in playerManager{player.loop();

前幾天投了Gameloft一份簡曆，結果人家的筆試題比較有個性，直接給我發過來了。就一個題，根據要示實現一個小遊戲，一星期的時間呵呵，人家也不怕你抄，可能要考驗自製力吧？我想還是不要參考別人的代碼了，不然自己的水平

突然心血來潮想學物理引擎了...以前老覺得這東西很神秘, 很高端...但是據說有高中物理水平就能用-_-剛來北京時配了一台很NB的台式機, 衝著物理加速和PerfHUD就買了塊9800GT, 一直沒發揮出它的潛力來, 天天拿它打dota, 汗~工作(算上實習的話)將近兩年了, 發現自己對於遊戲的熱情已經漸漸往技術方面轉移了最近幾個能讓我一口氣玩通的遊戲, 無一例外都使用了物理引擎: WorldOfGoo, CrayonPhysicsDeluxe, Trine...想想國內的遊戲,

http://stackoverflow.com/questions/423166/flash-activex-how-to-load-movie-from-memory-or-resource-or-streamvoid flash_load_memory(FlashWidget* w, void* data, ULONG size) { FlashMemoryStream fStream = FlashMemoryStream(data, size);

網路遊戲的自動更新很頻繁,而多數玩家會抱怨下載速度過慢同樣的,如果全部都從遊戲供應商的伺服器上下載,勢必導致網路資源的極大浪費,而且對於企業的補救伺服器和頻寬也是一個很大的考驗在PSP技術盛行的今天,為什麼不把這一技術應用到patchupdate中去呢?類似可以參考BT:BT下載實際上就是P2P下載的代表，該種下載方式與WEB方式正好相反，該種模式不需要伺服器，而是在使用者機與使用者機之間進行傳播，也可以說每台使用者機都是伺服器，講究"人人平等"的下載模式，每台使用者機在自己下載其它使用者機上檔

Copyright 1998 Geoff Howland--------------------------------------------------------------------------------"今天我有空就翻譯了一篇英文的遊戲文章, 是Game Artist類的。花了我有4 個小時, 你要是覺得還行就麻煩你放到你的首頁上吧, 我想再陸續翻譯一些比較好的遊戲製作理念方面的文章, 放在你的首頁上, 就當是為國內的遊戲製作諮訊添幾塊磚頭吧." By 餘建斌

最近看了一些PhysX的東西, 本想寫個demo練練手, 結果遇到一個非常詭異的問題當我興沖沖的用Wizard建了一個工程, 編譯, 運行, 竟然一片黑?奇怪啊, 這個Wizard程式應該沒問題才對, 要不然我怎麼敢發布出來?換成Release, 編譯...結果正常!用PIX跟蹤了一下發現, 兩個版本的變換矩陣不一樣!當時就茫然了...拿SDK內建的testviewer編譯運行了一下, debug版竟然是這樣的: 只能看到兩隻腳, 滑鼠操作沒有反應!太崩潰了~代碼肯定沒修改,

感謝gogoplayer提供的思路。 事情的經過是這樣的：幾天前gogoplayer跟我提到想用引用計數來解決訊息廣播時拷貝多份的問題，順帶提到boost::shared_ptr的引用計數是安全執行緒的。這一點跟我的記憶有出入，於是查boost的手冊確認了一下，發現從1.33.0開始shared_ptr就用了lock-free來實現安全執行緒，相當高效。 於是就想把原本的NetMessage隊列改為shared_ptr<NetMessage>隊列。這時回顧之前的實現方式，發現存在記憶

這裡使用的是之前我說過的OLE控制項在Direct3D中的渲染方法, 自己不進行swf的解析, 這不現實. 前提條件: COM編程, OLE編程, DirectX編程, ActionScript/Flash(可選).

一直以來這個blog不是轉載的就是學習筆記啥的, 沒多自己真正思考的東西可能因為自己還有另一個寫生活的blog, 勞騷全發那上面了不過看各位業內大牛在部落格上寫的一些自己思考的東西, 看了很有感觸.自己也應該寫點自己的想法吧, 起碼有些朋友看了會留個評論, 呵呵 今天在讀A Shader Appoach, 算是鞏固一下基礎知識吧看到一個函數:D3DXVec3Hermite. 突然想到不是有個Hermit Curve嗎? 呵呵, 這下做來畫曲線方便大了.

　　PL/0語言是Pascal語言的一個子集，我們這裡分析的PL/0的編譯器包括了對PL/0語言來源程式進行分析處理、編譯產生類PCODE代碼，並在虛擬機器上解釋運行產生的類PCODE代碼的功能。　　PL/0語言編譯器採用以文法分析為核心、一遍掃描的編譯方法。詞法分析和代碼產生作為獨立的子程式供文法剖析器調用。文法分析的同時，提供了出錯報告和出錯恢複的功能。在來源程式沒有錯誤編譯通過的情況下，調用類PCODE解釋程式解釋執行產生的類PCODE代碼。

最初在遊戲裡嵌入網頁用的是LLmozLib, 說實話, 還不錯, 用的FireFox的解析引擎但是它的編譯太麻煩了, 而且跟一些引擎代碼直接連結到一起的話還會衝突最讓人覺得不爽的是, 附帶了一大堆的DLL和資源檔 後來自己用IE的IWebBrowser2實現了一個嵌入瀏覽器, 除了捲軸拖動和效率還有點問題, 也基本上能用好處是相容性好, 也不用附帶什麼 後來看到google發布chrome後就一直在想這個東西能不能用在3D遊戲中, ubrowser的作者也在研究這個.

轉自決定採用Mercurial(Hg)了http://www.keakon.cn/bbs/thread-1865-1-1.html===================================================================最近想用版本控制軟體來儲存漢化檔案，但又覺得SVN太麻煩，於是想到了最近較為流行的分布式版本控制工具。而Git和Mercurial（意思為水銀的，於是經常縮寫為Hg）自然是其中最為流行的工具。大名鼎鼎的Linux就用Git作源碼管理，而

轉自http://blog.chinaunix.net/u2/87718/showart_1838217.html －－摘自《UNIX編程藝術》Unix哲學起源於Ken Thompson早期關於如何設計一個服務介面簡潔、小巧精乾的作業系統的思考，隨著Unix文化在學習如何儘可能發掘Thompson設計思想的過程中不斷成長，同時一路上還從其它許多地方博採眾長。

基礎的架構可以參考Demo/StandAloneDemos/ConsoleExampleMt搭建 如果只是用碰撞檢測的話, RigidBody整合進去就差不多了 HavokCloth&HavokDestruction是不是收費的? 竟然還有HavokAI和HavokScript Phantom不參與物理運算, 感覺只是一個地區的定義, 可以用來做觸發器什麼的吧 物理材質的參數是在哪編輯呢? 美術/策劃?(補充:外掛程式裡有) Constraint感覺很多遊戲都沒用上,

N3架構上是分了三層的, foundation, render, application.一直以來看的都是foundation和render, 上層的一直沒怎麼看今天大體上瀏覽了下, 感覺東西還是滿多的很多引擎都沒這一層的, 如果沒有實際項目的積累, 也沒法抽象出複用的部分來這裡說的Entity不是GraphicsEntity, 而是Game::Entity, 代表遊戲中的一個對象, 比如人, 道具什麼的一個Entity由以下幾部分組成:ID : 這個沒啥好說的AttributeTable:

第一級：神人，天資過人而又是技術狂熱者同時還擁有過人的商業頭腦，高瞻遠矚，技術過人，大器也。　　 　　第二級：高人，有天賦，技術過人但沒有過人的商業頭腦，通常此類人不是頂尖駭客就是技術總監之流。 　　 　　第三級：牛人，技術精湛，熟悉行業知識，敢於創新，有自己的公司和軟體產品。 　　 　　第四級：工頭，技術精湛，有領導團隊的能力，此類人大公司專案經理居多。 　　 　　第五級：技術工人，技術精湛，熟悉行業知識但領導能力欠加，此類人大多為系分人員或資深程式員，基本上桀驁不遜，自視清高，不願於一般技術

 　　聰明的腦袋是寶貴的有限的資源。當世界還充滿非常多有待解決的有趣的新問題時，它們不應該被浪費在重新發明輪子這類事情上。                            —— Eric S. Raymond