對我架設一個wow私服，意義有二：1. 玩wow過程中，碰到一些實現手法不解的地方，可以實時去調試。2. 基于此服務端模擬wow客戶端若干特性，比如地圖資源異步加載，角色并行狀態處理等。

需要工具：
1. visual studio 2010(arcemu trunk windows版本解決方案使用)，不建議強制修改visual studio版本，因為可能丟失工程配置參數信息。
2. mysql，SQLyog。（mysql數據庫不用說了，隨便什么版本，SQLyog主要是圖形化mysql命令操作）。
3. svn （因為是源碼編譯嘛）。

源碼下載：
1. 服務端程序arcemu trunk, https://arcemu.svn.sourceforge.net/svnroot/arcemu/trunk

2. 服務端使用的數據庫whydb, http://svn.xp-dev.com/svn/whydb-users
我是這樣放置代碼的 

編譯源碼：
1. 需要簡單地修改幾處源碼，一，src/scripts/src/InstanceScripts/Raid_ZulGurub.cpp中的第184行，將?/改成*/,很明顯這是手誤。二，src/arcemu-logonserver/LogonCommServer.cpp中的第313~314行注釋掉，解釋下情況：因為wow每個游戲服務器他們叫做Realm,每個Realm都要注冊到LogonServer中。考慮到不是我的Realm不能注冊到我的LogonServer，所以存在這授權處理的一關。我去掉主要是爛的去改配置文件。三，src/arcemu-world/HackFixes.cpp中第54~57行注釋掉，解釋下情況：因為官方只支持enUS和enGB，在加載spell.dbc的時候做了一個本地化核實。可以編譯了。
2. 創建3個數據庫arc_characters, arc_logon, arc_world.然后通過下圖的操作

分別將sql目錄下的3800_character_structure.sql導入到arc_characters里，將2834_logon_structure.sql導入到arc_logon里。然后再將sql/character_updates目錄里高于3800打頭的sql導入到arc_characters，同樣將sql/logon_updates目錄里高于2834打頭的sql導入到arc_logon。為什么不導arc_world？呵呵，因為源碼里帶的arc_world只是表結構定義，里面并沒有數據。這個要用whydb導入。進入whydb目錄，雙擊tool.bat就行了。

回車

繼續回車，就安裝好了。
然后在arc_logon的表accounts里加入幾個賬號：



重點說明下，此數據庫，服務端程式邏輯適用于3.3.5a版本，也就是wow大災變前夕的前一個版本。
所以必須準備一個3.3.5a版本的wow。我用的臺服的client，當然你用國服的也是一樣。很不幸的是我從3.0.3一個個patch打上來的。
如果你也想和我一樣過一過打patch的癮，你可以去http://tlax.5d6d.com/thread-1778-1-1.html一個個補丁下吧。
如下：



至于服務端configs里的*.conf，客戶端的登陸配置，上網上隨便找找就是了。
我要重點說下服務端適用的dbc和maps資源。如何從client取。
首先說dbc：編譯解決方案mpqe_cpp.sln，然后將extractdbc.bat，mpqe_cpp.exe，SFmpq.dll拷貝到Data/zhTW目錄下，然后執行bat就生成了dbc,然后將所有*.dbc拷貝到服務端的dbc目錄里。
再次說maps：編譯解決方案AD100.sln，然后將ad.exe拷貝到world of warcraft目錄，和data同層，然后再將Data/zhTW里的locale-zhTW.MPQ拷貝到Data里（因為這個程序比較傻，他沒有遞歸遍歷到所有的檔案，他想從locale-zhTW.MPQ里去找Map.dbc），然后執行ad.exe，然后將maps里所有的.bin文件拷貝到server的maps里就ok了，基本配置配置就可以跑了。
有什么不清楚的再討論吧。

1.當template parameters和call parameters之間沒有明顯聯系，而且編譯器無法推導出template parameters時，必須明確地再調用時指定template arguments
2.如果template parameters作為返回類型，那么也必須顯式地指定template parameters，不過你可以把這個返回類型放在template parameters的第一個位置，只指定第一template parameters,其他的讓編譯器去推導。
3.就像functions一樣，function templates也可以被重載。
4.在編譯的過程中，編譯器會根據每次具體使用的函數（帶有template的function），來生成具體的函數代碼實例。
5.在自變量推導過程中，惟有當參數不是一個reference類型時，array才會退化為pointer（通過稱為退化）。
6.function template或class template的implement必須放在.hw文件里。常規的編程方法是把function或class的declare放在.h的文件中，把implement放在.cpp中，對應declare的implement已經在編譯時生成了編譯符號，所以可以在運行時調用。而function template或class template不同，它要針對具體的template parameters去生成不同的實例，而這個過程不會去多次解析放在cpp中的實現。

事件機制最大的好處就是實現了偽并行。 os層提供了thread通過切換時間片來實現軟件層面最真的并發。 事件機制處理，通過遍歷一個事件的若干個訂閱者來實現出類型的并發。

在系統級開發，往往需要暴露出一些api給用戶使用，暴露出來的api，就像做了一個sandbox（沙箱）給孩子玩耍一樣，孩子不會破壞到外面的世界。

在linux下的命令共有三種，例子說明： 1.ls -l. 這種是unix類的命令參數風格。 2.ls --help. 在linux發展，需要擴展unix的命令參數，就用這種形式。 3.ls -version，在linux圖形化過程又擴充了之前的命令參數。

1.當存在線程或中斷切換上下文時。 2.變量類型為寄存器類型（整形，bool等）。

這幾天自己做了一個編輯器，轉了一大圈又回到了用例。對需要實現什么功能模棱兩可，害的一遍遍重構，后來才發現出在用例上。用例太重要了。
在做這款軟件，我需要明確知道我需要它做什么，我的軟件就要圍繞著它的用途逐一展開。如果在用例的時候就扭曲了，最后它就像一篇走了題的作文，技巧用的再多那都毫無價值。至于類圖設計階段，要盡量做到類體積均衡，一類負責一事。設計類的時候，內存模型，線程模型作為基準。盡量少用內存，在不影響效率的情況下用new。做好new對內存環境潛在的破壞修復。以及后面時序圖階段，保證某一條或某幾條時序執行效率（io效率，循環中無效剔除效率）。

序列化文件可能要注意的幾點：（不足給予補充）
1.不同cpu體系結構的硬件所支持的字節序不同，所以序列化的目標數據要以一種字節序為主，一般分為小端，大端，本地端（根據程序運行的機器來的）。
2.在序列化的時候就要考慮反序列化的一些便利，可以對原始數據類型做分類，所有組合原始數據的高級數據一般通過索引原始數據來獲取（這樣也降低了數據冗余），這樣你就可以保證數據的chunk化。
3.盡可能地讓文件格式不同于其他，為了此文件格式的擴展可以做一些版本指定。
4.如果你考慮到serialize的靈活性，就一定要抽象device以及stream這2個概念，device控制著使用什么stream去讀寫，而stream直接操縱buffer，所以在stream你可以控制讀寫數據的安全性（多線程）與效率。

5.現在不只考慮serialize單個文件，而考慮序列化一個文件層次結構到硬盤，一般會抽象出個archive來，這個archive存儲在硬盤上，所以首先這些數據的序列化必須滿足os的文件系統格式（這個不用擔心了，直接操作FILE，fstream就ok了），而后為了數據包裝（一是為了安全，二是為了大小，三是為了不凌亂），我們一般要對archive進行拓展，拓展archive的行為，比如在內存寫到硬件這個基本函數的進行壓縮并加密，而在硬盤恢復到內存這個基本函數上進行解壓縮并解密，這里存在個問題，archive不是一次性讀取到內存，所以最好給每個archive做個頭數據，至少保證這個頭數據一定要讀到內存，頭數據的意義就是選擇性地讀取archive的數據段，羅列archive的層次結構等（至于大小寫敏感的問題，盡量做一些協調）。

早前一直被這個問題困惑，但是自己推倒了很多遍也沒推出來。
哎，在gameres上搜了3年前的談話，后來在gamedev搜到了答案。
其實在計算機圖形學中，只要是變換，無論平移，旋轉，縮放，都是乘一個矩陣。
在模型視圖變換時，頂點乘模型視圖變換矩陣，而頂點對應的頂點法線向量（或其他的法線向量）則要乘模型視圖矩陣的逆轉置矩陣。
頂點和法線都是向量，他們的區別是什么？無非頂點是<x, y, z>表示缺省的<x, y, z, 1>，而法線向量是<x, y, z>表示缺省的<x, y, z, 0>。關于為什么是這樣，不用我說了吧，2個頂點向量減下看看就知道了。
從這點來看，確實不同，或許就是這個不同，造成了變換的不同吧。
法線向量只能保證方向的一致性，而不能保證位置的一致性，所以，所有線向量必須以面的形式進行變換，如下：

Transforming Planes

If we have a plane vector n = [a, b, c, d] which describes a plane then for any point p = [x, y, z, 1] in that plane the follow equation holds:

n^t p = ax + by + cz + d = 0

If for a point p on the plane, we apply an invertible transformation R to get the transformed point p₁, then the plane vector n₁ of the transformed plane is given by applying a corresponding transformation Q to the original plane vector n where Q is unknown.

p₁ = R p
n₁ = Q n

We can solve for Q by using the resulting plane equation:

n₁^t p₁ = 0

Begin by substituting for n₁ and p₁:

(Q n)^t (R p) = 0
n^t Q^t R p = 0

If Q^t R = I then n^t Q^t R p = n^t I p = n^t p = 0 which is given.

Q^t R = I
Q^t = R^-1
Q = (R^-1)^t

Substituting Q back into our plane vector transformation equation we get:

n₁ = Q n = (R^-1)^t n

公司的平臺只編譯了release版，我們就必須在release下寫具體實現。（依賴release寫debug會出問題）
可惡的是，我的代碼對象層次頗多，所以我寫了很多小函數，這些小函數在release版本下默認是內聯的。
就這樣造成了悲劇，過多的內聯，把調試器都晃暈了，索性，我把編譯優化關了，發現dll膨脹到2倍。