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

網絡和流協議，文件打包，讀取，等等一工作基本工作總算是完工了，現在人物可以在我的場景中漫游，人物和人物之間通過網絡能相互通訊，都已經實現了，但是回頭再看看我的場景，實在是汗顏啊，場景十分單調，之前我是把場景對象放入到一個大的XML文件中的，完全手工來編輯XML，因為沒有自己的場景編輯器，唉，一直下不了決心去寫啊。

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

進行了簡單的設計之后，初步我打算用MDI窗口來制作場景編輯器，工具，參數調節面板在兩旁，中間是D3D窗口
可才開始，就碰到問題了，天哪，MFC的主循環在哪里呢？How about Continuous Updating and Rending in MFC ?

不過功夫不負有心人，總算查到了，不過研究了好一會兒，還好有了結果

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

其實也是有解決方法的，請看下文：

//你需要重寫你的應用程序的Run()方法，把原方法里面的代碼統統復制過來下面都是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 (;;)
 {
 
 //偷看消息隊列，如果沒有消息的話，就執行游戲的主循環框架完成渲染的Update
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
 while(!::PeekMessage(&(pState->m_msgCur), NULL, NULL, NULL, PM_NOREMOVE))
  {
   //這里就可以放游戲的主循環了
   //GameLoop();
   DBWindowWrite("hello \r\n");
  }
//加入上面這段就搞定了，這個方法里面的其他的代碼就不要去動他們的了，否則 ^_^!
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

  // 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消息處理機制，類似于消息泵，有消息就處理消息
   // 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));
 }
}

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

無論如何，現在開工吧！

     摘要: 關于資源包的新的比較完善的想法，模仿文件或數據庫系統內部的數據組織結構，這里只是來談談原理和思路，我還沒實現  閱讀全文

     摘要:   閱讀全文

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

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

ObjectStream
StreamBuffer
SerializeMap
PacketStruct
...

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

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

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

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

這些是寫完成了，回頭看看自己已經寫好的網絡邏輯模塊，犯愁了。
唉……，加入序列化，相當于高層次的通訊協議全都變了，包結構要改，所有的業務邏輯通訊代碼隨之要改。

之前的工作…… 又要寫大量的重構代碼了。

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

現在，只能告訴自己一件事，沉下心，沉注氣。

雖然,網絡編程里面的數據傳送推薦用序列化,但我不用,還是選擇結構體(返璞歸真),有以下幾點理由:
1.跨平臺問題：
  序列化確實可以很好的跨語言平臺,可大多數網絡游戲不需要跨語言平臺

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

3.結構體存在內存對齊和CPU不兼容的問題，可以避免
  的確結構體是有內存對齊的問題,存在兼容性問題,我可以選擇pack(1)把內存對齊給關閉掉,避免兼容性問題,既然選擇了iocp就不打算跨平臺了,可以避免結構體平臺兼容的問題

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

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

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

7 平臺擴充問題
  退一萬步的說：換了語言就基本上換了客戶端，客戶端的數據組織形式都要重寫
  實在不行還可以考慮用xml json 編碼等等一些跨平臺的解決方案，現在所寫的結構體是可以用來做數據接收的，只是發送的不再是結構體而已

8.綜上所述
  如果需要跨語言平臺，不用序列化（二進制流或xml, json文本等等）根本無法實現
  序列化的優點還是非常多的.如果主要是跨平臺和語言自定義讀寫規則,根據需要讀寫對象的某一部分數據,
  空間浪費少,不存在內存對齊問題等諸多優點，缺點就是拐彎抹角，代碼量大，調試不方便

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

我知道：序列化很好很強大，很多網絡程序高手根本不屑于直接發一個邏輯結構體，用這種方式就好象是旁門左道，狗肉上不了大雅之堂一樣，狗肉還是很多人喜歡吃的嘛，：）。

我還是返璞歸真選擇了結構體

一句話：物盡其用，用的恰當，夠用就好。

如果有什么不對，敬請拍磚，莫要客氣

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

這次帶給我的經驗是，當程序框架越來越大的時候
一個錯誤可能是由幾個模塊的任何一個模塊導致的，測試任何一個大的模塊都是傷精動骨的事
一個樁模塊可能對應N個驅動模塊，測起來很不容易。
一開始做好單元測試的工作太重要了。

新的問題總是會不斷的出現，也得要一個個的掃除之~!!!!!

     摘要: 做了個包容器，一次可以發多個變長邏輯結構了體了，爽啊。  閱讀全文

過去用戶斷開，其他用戶不知道，也就出現了鬼影，現在剛有時間完善了這塊，某人一下線，周圍的人立馬就知道了，另外人物移動和周圍的人物通訊，已經基本實現，只是有些細節部分還不完善。這是個細致活。還要繼續加油啊～！！！

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