3d Game Walkman

     摘要: 我的大地形的頂點(diǎn)的凹凸都可以用可視化的方式進(jìn)行編輯了，慶祝一下~!!!  閱讀全文

網(wǎng)絡(luò)和流協(xié)議，文件打包，讀取，等等一工作基本工作總算是完工了，現(xiàn)在人物可以在我的場(chǎng)景中漫游，人物和人物之間通過網(wǎng)絡(luò)能相互通訊，都已經(jīng)實(shí)現(xiàn)了，但是回頭再看看我的場(chǎng)景，實(shí)在是汗顏啊，場(chǎng)景十分單調(diào)，之前我是把場(chǎng)景對(duì)象放入到一個(gè)大的XML文件中的，完全手工來編輯XML，因?yàn)闆]有自己的場(chǎng)景編輯器，唉，一直下不了決心去寫啊。

從今天開始，我打算自己自作一個(gè)場(chǎng)景編輯器，這可是一個(gè)大工程啊，不過應(yīng)該是很值的，如果能完善，那才真就有引擎的架式了
可能你會(huì)問，現(xiàn)在也有很多免費(fèi)的引擎還自己寫？
是啊，我的無限大地形是核心，里面溶入了我太多的心血，很多實(shí)現(xiàn)和別人的自然“不完全兼容”了，如今是時(shí)候了……

進(jìn)行了簡單的設(shè)計(jì)之后，初步我打算用MDI窗口來制作場(chǎng)景編輯器，工具，參數(shù)調(diào)節(jié)面板在兩旁，中間是D3D窗口
可才開始，就碰到問題了，天哪，MFC的主循環(huán)在哪里呢？How about Continuous Updating and Rending in MFC ?

不過功夫不負(fù)有心人，總算查到了，不過研究了好一會(huì)兒，還好有了結(jié)果

那么說到正題，怎么在MFC應(yīng)用程序里面加入主循環(huán)呢，MFC的WinMain可是看不到的哦，消息處理都做了高度封裝

其實(shí)也是有解決方法的，請(qǐng)看下文：

//你需要重寫你的應(yīng)用程序的Run()方法，把原方法里面的代碼統(tǒng)統(tǒng)復(fù)制過來下面都是copy的CWinApp::Run()的源碼

int CMapEditorApp::Run()
{
 //return CWinApp::Run();
 if (m_pMainWnd == NULL && AfxOleGetUserCtrl())
 {
  // Not launched /Embedding or /Automation, but has no main window!
  TRACE(traceAppMsg, 0, "Warning: m_pMainWnd is NULL in CWinApp::Run - quitting application.\n");
  AfxPostQuitMessage(0);
 }

 ASSERT_VALID(this);
 _AFX_THREAD_STATE* pState = AfxGetThreadState();

 // for tracking the idle time state
 BOOL bIdle = TRUE;
 LONG lIdleCount = 0;

 // acquire and dispatch messages until a WM_QUIT message is received.
 for (;;)
 {
 
 //偷看消息隊(duì)列，如果沒有消息的話，就執(zhí)行游戲的主循環(huán)框架完成渲染的Update
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
 while(!::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE))
  {
   //這里就可以放游戲的主循環(huán)了
   //GameLoop();
   DBWindowWrite("hello \r\n");
  }
//加入上面這段就搞定了，這個(gè)方法里面的其他的代碼就不要去動(dòng)他們的了，否則 ^_^!
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

  // phase1: check to see if we can do idle work，處理線程
  while (bIdle &&
   !::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE))
  {
   // call OnIdle while in bIdle state
   if (!OnIdle(lIdleCount++))
    bIdle = FALSE; // assume "no idle" state
  }
       
  // phase2: pump messages while available
  do
  {
   //windows自己的GetMessage消息處理機(jī)制，類似于消息泵，有消息就處理消息
   // pump message, but quit on WM_QUIT，
   if (!PumpMessage())
    return ExitInstance();

   // reset "no idle" state after pumping "normal" message
   //if (IsIdleMessage(&m_msgCur))
   if (IsIdleMessage(&(pState->m_msgCur)))
   {
    bIdle = TRUE;
    lIdleCount = 0;
   }

  } while (::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE));
 }
}

這只是一個(gè)初步的開始，MFC可不是一個(gè)好東西，這到不算什么，地圖編輯器才是最麻煩的東西。
唉～～～

無論如何，現(xiàn)在開工吧！

     摘要: 關(guān)于資源包的新的比較完善的想法，模仿文件或數(shù)據(jù)庫系統(tǒng)內(nèi)部的數(shù)據(jù)組織結(jié)構(gòu)，這里只是來談?wù)勗砗退悸罚疫€沒實(shí)現(xiàn)  閱讀全文

     摘要:   閱讀全文

前面的文章也提到了，看了一些服務(wù)器的大師級(jí)的代碼，SmartStruct和自定義序列化的方式都有，如果單單只用C結(jié)構(gòu)體作為語意數(shù)據(jù)載體固然可以，但很多網(wǎng)友也提出了很多質(zhì)疑，最大的缺陷就是靈活性欠佳，誠然如此。

這段時(shí)間沉下了心，好好寫了一些類主要有：

ObjectStream
StreamBuffer
SerializeMap
PacketStruct
...

等等，有了前人的經(jīng)驗(yàn)，似乎也算比較順利，一個(gè)個(gè)從基本的數(shù)字，
到數(shù)組，到char[] (很多資料也稱之為：raw 二進(jìn)制序列)
再到STL 的一系列容器的序列化工作都實(shí)現(xiàn)了

其中大量使用了模版類的泛型設(shè)計(jì)，不必要求一個(gè)可序列化的類必須繼承某某基類，只需要具備以下：

 SerializeTag ComputeTag();
 bool Read(ObjectStream& stream);
 bool Write(ObjectStream& stream);
 DWORD GetLength(ObjectStream& stream);
 bool operator==(const PacketHeader &other) const;

五個(gè)方法就可以了，如果隨意給你一個(gè)事先定義好的類，可以實(shí)現(xiàn)序列化嗎？當(dāng)然可以，只需要寫出該類的
Wrapped Proxy，再添加這5個(gè)方法，就能通過 ObjectStream 和 StreamBuffer 實(shí)現(xiàn)該類的序列化了

這些是寫完成了，回頭看看自己已經(jīng)寫好的網(wǎng)絡(luò)邏輯模塊，犯愁了。
唉……，加入序列化，相當(dāng)于高層次的通訊協(xié)議全都變了，包結(jié)構(gòu)要改，所有的業(yè)務(wù)邏輯通訊代碼隨之要改。

之前的工作…… 又要寫大量的重構(gòu)代碼了。

重構(gòu)真是件痛苦的事情。
最壞的打算把之前的一些邏輯東西按現(xiàn)有思路重寫一遍嘛，二次加工也許能應(yīng)禍得福，把破舊看不過眼的地方重整理的更漂亮，好比重新裝修升級(jí)一樣

現(xiàn)在，只能告訴自己一件事，沉下心，沉注氣。

雖然,網(wǎng)絡(luò)編程里面的數(shù)據(jù)傳送推薦用序列化,但我不用,還是選擇結(jié)構(gòu)體(返璞歸真),有以下幾點(diǎn)理由:
1.跨平臺(tái)問題：
  序列化確實(shí)可以很好的跨語言平臺(tái),可大多數(shù)網(wǎng)絡(luò)游戲不需要跨語言平臺(tái)

2.別以為有了序列化就不需要結(jié)構(gòu)體
  表面上序列化代碼量小，按順序讀和寫char int short LPCSTR ... 就好，邏輯對(duì)象寫不寫都無所謂，那就是大錯(cuò)而特錯(cuò)了
  待序列化的對(duì)象發(fā)送前的結(jié)構(gòu)還是不可省略的序列化的過程就是 object->(按一定順序拆分)write->bytes->(按拆分順序組裝)read->object的過程
 其實(shí)object還是不能省略,很多人寫網(wǎng)絡(luò)程序不注重邏輯對(duì)象結(jié)構(gòu),收到的一堆bytes按一定順序讀和寫就完事了,這樣雖然靈活,但缺乏結(jié)構(gòu),容易造成混亂，調(diào)試起來是災(zāi)難
   所以結(jié)構(gòu)體（或類）還是省略不了的，所以：別以為有了序列化，就不需要結(jié)構(gòu)體了。

3.結(jié)構(gòu)體存在內(nèi)存對(duì)齊和CPU不兼容的問題，可以避免
  的確結(jié)構(gòu)體是有內(nèi)存對(duì)齊的問題,存在兼容性問題,我可以選擇pack(1)把內(nèi)存對(duì)齊給關(guān)閉掉,避免兼容性問題,既然選擇了iocp就不打算跨平臺(tái)了,可以避免結(jié)構(gòu)體平臺(tái)兼容的問題

4.結(jié)構(gòu)體調(diào)試起來方便很多，減少內(nèi)存拷貝，效率高
  不用序列化可write和read的過程就不需要過多考慮（少寫太多代碼了），read write 就好像現(xiàn)代社會(huì)每個(gè)人每天都要穿衣服和脫衣服一樣，原始社會(huì)需要嗎？其實(shí)人類進(jìn)化到原始裸奔狀態(tài)才是最爽快的:)
  但還是要說句公道話：有人說序列化編碼解碼read write 需要耗費(fèi)資源, 誠然這個(gè)過程基本等于賦值和內(nèi)存拷貝，那點(diǎn)效率損失主要還在內(nèi)存拷貝上，這點(diǎn)效率損失很小，不能作為序列化的缺點(diǎn)，當(dāng)然如果涉及到數(shù)據(jù)加密那將是另外一個(gè)話題

5.結(jié)構(gòu)體貌似呆板，發(fā)送數(shù)據(jù)限制多，發(fā)送變長數(shù)據(jù)就不方便，數(shù)據(jù)組織起來也不靈活
  我想這是很多人拋棄結(jié)構(gòu)體，選擇用序列化方式發(fā)送和接受數(shù)據(jù)的一個(gè)很重要的原因
  但：其實(shí)對(duì)于變長結(jié)構(gòu)(子結(jié)構(gòu)也是變長)的問題,用結(jié)構(gòu)體來實(shí)現(xiàn)的確很麻煩,但并不代表不能實(shí)現(xiàn)
  我已經(jīng)實(shí)現(xiàn)了,而且讀和寫變長子結(jié)構(gòu)體嵌套任意多層都不成問題,可以存儲(chǔ)復(fù)雜變長的數(shù)據(jù)結(jié)構(gòu)，
  數(shù)據(jù)就如同能自動(dòng)序列化一樣方便，這個(gè)應(yīng)該是技術(shù)難點(diǎn)，但細(xì)心去做是可以實(shí)現(xiàn)的

6.關(guān)于結(jié)構(gòu)體指針
  游戲里面要發(fā)送的數(shù)據(jù)內(nèi)存事先分配好的，不存在指針,深度復(fù)制更不用考慮，所以內(nèi)存拷貝不會(huì)出錯(cuò)
  如果用到指針即使用序列化來實(shí)現(xiàn)也會(huì)面臨同樣的問題也占不了多少便宜，由于C++這們語言的特點(diǎn)，
  不象java那樣有個(gè)標(biāo)準(zhǔn)實(shí)現(xiàn),對(duì)于序列化本身沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)，所以可想而知，有人說:boost有它的序列化的實(shí)現(xiàn)
  其實(shí)那個(gè)實(shí)現(xiàn)不見得就合適你自己，如果真要做序列化，編碼和解碼的仿照那個(gè)過程自己寫才最為牢靠，
  哪些指針對(duì)應(yīng)的內(nèi)存需要序列化那些不需要序列化，是個(gè)邏輯結(jié)構(gòu)，需要自己說了算才好（好像扯遠(yuǎn)了點(diǎn)）
  說回游戲數(shù)據(jù)，既然不用需要他用到指針，結(jié)構(gòu)體用來發(fā)送數(shù)據(jù)也沒問題的

7 平臺(tái)擴(kuò)充問題
  退一萬步的說：換了語言就基本上換了客戶端，客戶端的數(shù)據(jù)組織形式都要重寫
  實(shí)在不行還可以考慮用xml json 編碼等等一些跨平臺(tái)的解決方案，現(xiàn)在所寫的結(jié)構(gòu)體是可以用來做數(shù)據(jù)接收的，只是發(fā)送的不再是結(jié)構(gòu)體而已

8.綜上所述
  如果需要跨語言平臺(tái)，不用序列化（二進(jìn)制流或xml, json文本等等）根本無法實(shí)現(xiàn)
  序列化的優(yōu)點(diǎn)還是非常多的.如果主要是跨平臺(tái)和語言自定義讀寫規(guī)則,根據(jù)需要讀寫對(duì)象的某一部分?jǐn)?shù)據(jù),
  空間浪費(fèi)少,不存在內(nèi)存對(duì)齊問題等諸多優(yōu)點(diǎn)，缺點(diǎn)就是拐彎抹角，代碼量大，調(diào)試不方便

權(quán)衡了良久
  數(shù)據(jù)如果能組織的合理，而且沒有跨語言平臺(tái)的要求，用結(jié)構(gòu)體也未嘗不可,畢竟數(shù)據(jù)發(fā)送直來直去還是方便些，減少內(nèi)存拷貝，效率也高了很多
  特別是調(diào)試起來容易太多了，衡量利弊我還是放棄了序列化，選擇了原始的結(jié)構(gòu)體，只是難在數(shù)據(jù)的組織（好在基本已經(jīng)克服了）

我知道：序列化很好很強(qiáng)大，很多網(wǎng)絡(luò)程序高手根本不屑于直接發(fā)一個(gè)邏輯結(jié)構(gòu)體，用這種方式就好象是旁門左道，狗肉上不了大雅之堂一樣，狗肉還是很多人喜歡吃的嘛，：）。

我還是返璞歸真選擇了結(jié)構(gòu)體

一句話：物盡其用，用的恰當(dāng)，夠用就好。

如果有什么不對(duì)，敬請(qǐng)拍磚，莫要客氣

過去的老代碼庫里隱藏很深的臭蟲，被我逐個(gè)抓了出來，一共三個(gè)用了我足足兩天的時(shí)間，雖然兩天才找了3個(gè)bug但自我感覺很值得。
程序運(yùn)行起來不會(huì)象過去那樣不穩(wěn)定了。
還是很暢快的，這下我好集中精力攻克后面的內(nèi)容

這次帶給我的經(jīng)驗(yàn)是，當(dāng)程序框架越來越大的時(shí)候
一個(gè)錯(cuò)誤可能是由幾個(gè)模塊的任何一個(gè)模塊導(dǎo)致的，測(cè)試任何一個(gè)大的模塊都是傷精動(dòng)骨的事
一個(gè)樁模塊可能對(duì)應(yīng)N個(gè)驅(qū)動(dòng)模塊，測(cè)起來很不容易。
一開始做好單元測(cè)試的工作太重要了。

新的問題總是會(huì)不斷的出現(xiàn)，也得要一個(gè)個(gè)的掃除之~!!!!!

     摘要: 做了個(gè)包容器，一次可以發(fā)多個(gè)變長邏輯結(jié)構(gòu)了體了，爽啊。  閱讀全文

過去用戶斷開，其他用戶不知道，也就出現(xiàn)了鬼影，現(xiàn)在剛有時(shí)間完善了這塊，某人一下線，周圍的人立馬就知道了，另外人物移動(dòng)和周圍的人物通訊，已經(jīng)基本實(shí)現(xiàn)，只是有些細(xì)節(jié)部分還不完善。這是個(gè)細(xì)致活。還要繼續(xù)加油啊～！??！

     摘要: 對(duì)于線程資源共用問題，實(shí)際上也沒有一個(gè)最完美的解決方案，沒有最適合的，只有根據(jù)情況來分析，找合適的方法，我最近在做角色之間的位置信息交換，已經(jīng)實(shí)現(xiàn)了一部分了。感覺很爽  閱讀全文