一直不是很清除VC的斷點(diǎn)保存于何處，讓我們看幾個(gè)證據(jù)：

1. 多人開發(fā)中，經(jīng)常更新別人的代碼后，突然停在某個(gè)自己沒打過的斷點(diǎn)上，我們組稱之為附送斷點(diǎn)。
2. 并且無論VSS還是SVN等代碼管理工具都會(huì)出這樣的問題。但是你提交的只有代碼，沒有其他單獨(dú)的配置文件
3. VC2005中，即便打過SP1，也會(huì)碰到某個(gè)文件突然無法打斷點(diǎn)的BUG（排除沒有重編，打錯(cuò)文件斷點(diǎn)等低級(jí)錯(cuò)誤），解決辦法是：打開記事本，將這個(gè)文件的代碼全部粘貼到記事本，再帖回來
4. VB中的代碼文件，使用記事本打開時(shí)，可以看到比IDE里看到更多的配置型代碼

綜上所述，基本可以斷定VC的斷點(diǎn)被保存于代碼的尾部的某個(gè)位置，看不見的一些字符

    目前項(xiàng)目中使用Flash為主設(shè)計(jì)的UI，因?yàn)榧嫒菪詥栴}，F(xiàn)lash中編輯框雖然可以輸入中文，但是光標(biāo)是看不到閃爍的。經(jīng)過仿佛研究發(fā)現(xiàn)，必須將d3d 的flash容器程序在后臺(tái)時(shí)，才能顯示光標(biāo)，這一個(gè)測試結(jié)果讓我們雷的不行。最終決定將flash拆解開，每個(gè)界面一個(gè)flash。但依然發(fā)現(xiàn)很多影響開發(fā)效率的問題。

    GameBryo引擎中支持原生的C++ GAME UI，也支持直接播放flash，這部分（ScaleForm）使用的是以GameSwf為基礎(chǔ)的手動(dòng)解析flash文件，因此在編輯框等方面做的非常好。

    Flash的UI開發(fā)靈活度很高，底層庫bug少，但是與現(xiàn)有工程結(jié)合難度大，因此仍然轉(zhuǎn)向研究以XML為基礎(chǔ)的UI庫設(shè)計(jì)。

    這里推薦幾個(gè)參考：

    WowBench： http://sourceforge.net/projects/wowbench/

        這是魔獸世界的UI的模擬器，開源，可以從中了解魔獸世界的基本UI架構(gòu)及API構(gòu)成。同時(shí)，魔獸的lua腳本在安全性和開發(fā)度上做的非常好，這部分可以參考下。

    Mozilla XUL：https://developer.mozilla.org/En/XUL

        這是Mozilla戰(zhàn)略中的一個(gè)重要組成部分，這套UI支持類似于wxWidgets或者HTML方式的排版

    騰訊新產(chǎn)品線：QQ2009, QQ 旋風(fēng)2，QQ影音等都使用了非常漂亮的界面。一直以為是自己寫的，畢竟QQ2009需要一個(gè)安全的環(huán)境以避免外掛的衍生。經(jīng)過spy++探測，發(fā)現(xiàn)一個(gè)TXGuiFoundation，再在網(wǎng)上一搜，搜到了這個(gè)東西：

    DSkinLite: http://uieasy.cn/downloads.html

     Dskinlite 是一款輕量級(jí)的C++皮膚庫，使用XML文件根據(jù)規(guī)則來管理GDI資源如顏色，字體，圖片，并描述界面構(gòu)成，最大程度的將界面和程序邏輯分離，同時(shí)為軟件皮膚更換，換色等提供基礎(chǔ)支持。DSkinLite將界面構(gòu)成元素抽象為線條元素，矩形元素，圖片元素，文本元素，并提供相應(yīng)規(guī)則來使用這些元素"組合"界面。DSkinlite開發(fā)團(tuán)隊(duì)有較深的Windows界面開發(fā)的實(shí)際經(jīng)歷，對(duì)軟件界面處理頗有心得，致力于將實(shí)用，高效，前沿的界面處理技術(shù)介紹給廣大開發(fā)人員。

        DSkinLite與其他界面庫相比有以下特點(diǎn)： 沒有采用Hook所有進(jìn)程消息的方式，因此沒有替換系統(tǒng)相關(guān)對(duì)話框。DSkinLite只是采用MFC，ATL等framework類似的方式，簡單替換窗口過程，截取界面繪制等消息，對(duì)應(yīng)用程序來說基本上是透明的。從這個(gè)方面講，DSkinLite是一款輕量級(jí)的界面庫。 同時(shí)，DSkinLite沒有特別的Frameword的依賴，可以在Win32，MFC,ATL,WTL等環(huán)境中使用。 DSkinLite界面庫使用XML管理GDI資源并配置窗口界面，用戶可以方便的保持界面的一致性，同時(shí)可以很方便的構(gòu)造出更多的窗口樣式 界面庫的高效性。DSkinLite將專注于程序庫的高效性，具體表現(xiàn)在內(nèi)存占用，界面繪制速度，界面防止閃爍，程序加載圖片資源、解析XML文件的速度等方面，我們做了很多工作，并不斷持續(xù)優(yōu)化。以期望程序各方面表現(xiàn)最為高效的界面程序庫。 
        DSkinLite 皮膚庫的程序架構(gòu)考慮到可能出現(xiàn)的界面特效，使得實(shí)現(xiàn)諸如透明，漸隱漸顯，動(dòng)畫等界面特效變得更加容易，目前支持大多數(shù)控件的透明效果，后續(xù)會(huì)根據(jù)用戶需求，開發(fā)更多的實(shí)用的界面特效。

使用XML配置控件的界面

• 使用XML定義GDI資源（顏色，字體，圖片，cursor）
• 使用XML配置控件的界面風(fēng)格
• 繪制元素被抽象為線條，文本，矩形，圖片
•  

  XML語法簡單，易于學(xué)習(xí)和掌握

   

  其他關(guān)鍵特性

   

• 基于Win32 API，沒有framework依賴。
• 支持大多數(shù)標(biāo)準(zhǔn)控件
• 支持改變皮膚色調(diào)
• 支持大多數(shù)控件透明，包括子窗口透明
• 支持動(dòng)畫效果
• 支持png, bitmap, gif, ico圖片格式。支持帶透明通道的png圖片
• 支持將皮膚文件打包到一個(gè)文件
• 支持Unicode
• 支持Popup Menu等，包括不規(guī)則的menu window
•  

  支持滾動(dòng)條控件，同時(shí)支持所有內(nèi)置滾動(dòng)條控制

     

  該網(wǎng)站還提到一個(gè)DirectUI的東西，這個(gè)東西是一種windowless的架構(gòu)，具體概念類似于游戲中的UI，不依賴平臺(tái)句柄，因此外掛只能截取諸如QQ基于ATL的外窗口，但是無法獲取窗口內(nèi)部的數(shù)據(jù)

????Svn現(xiàn)在已經(jīng)是非常流行的代碼管理，雖然vss更容易接受。但是真正方便的而強(qiáng)大的卻是git。

????這個(gè)東西沒有獨(dú)立服務(wù)器提交代碼，每個(gè)本地都是一個(gè)代碼庫，包括log等等。而且代碼管理文件夾不像svn每個(gè)文件夾都有，更不像vss用只讀文件的巨傻辦法來做，git使用的是獨(dú)立一個(gè)文件夾來做，簡單而又簡潔

????這里記錄git的安裝方法和使用說明以便下次快速索引

????說明和下載：http://hi.baidu.com/mcspring/blog/item/171b1e38986d39fab211c71b.html

使用指南：http://www.linuxgem.org/2008/8/1/git-tutorial.4889.html

一分鐘指南：http://blog.enjoyrails.com/2008/12/31/git一分鐘教程/

更直觀的教學(xué)：http://hi.baidu.com/proteus/blog/item/6ec19322c2a39cf4d6cae22d.html

    10年前的廣播節(jié)目中大概都有這么一個(gè)設(shè)計(jì)：某某節(jié)目開始，讓聽眾打進(jìn)電話。一般不會(huì)像聲訊臺(tái)那樣設(shè)置很多的接線員，因此電臺(tái)會(huì)設(shè)置一個(gè)導(dǎo)播來接聽電話，打不進(jìn)來的聽眾就只有在接通電話后等待著。這樣做，用戶體驗(yàn)其實(shí)并不好，時(shí)間長了，別人會(huì)認(rèn)為怎么你那電話怎么老是打不進(jìn)來。

    四川電臺(tái)經(jīng)濟(jì)廣播每天早上9點(diǎn)開始的人氣節(jié)目《方言社會(huì)》是這樣設(shè)計(jì)的：主持人會(huì)隨機(jī)選擇一條成都的街道，讓在這條街道上的聽眾打進(jìn)電話來說他看到了什么，然后獲贈(zèng)諸如電影票之類的東西。這樣分析下來，沒有在那條街上的人自然也就不會(huì)打進(jìn)電話進(jìn)去。畢竟在那條街上還聽這個(gè)節(jié)目的聽眾比起整個(gè)四川人口來說還是算少數(shù)。

    因此這就是很好的一個(gè)負(fù)載平衡的小例子

    最近聊天系統(tǒng)測出一個(gè)問題：測試人員使用的是韓文操作系統(tǒng)，在上面安裝了搜狗中文輸入法。他們互相之間發(fā)送韓文聊天是沒有亂碼的，但是我們和他們互相以中文發(fā)送時(shí)，會(huì)出現(xiàn)亂碼情況。隨即進(jìn)行測試發(fā)現(xiàn)以下問題：

    對(duì)于 "德國"

    他們發(fā)送的編碼數(shù)據(jù)為 d3 ec 3f

    而我們的中文系統(tǒng)為 b5 c2 b9 fa

    因?yàn)榱奶煜到y(tǒng)采用ANSI的架構(gòu)，但是為什么同是東方語言系，一個(gè)會(huì)是UTF8,一個(gè)是ANSI雙字節(jié)，因此將聊天系統(tǒng)整體發(fā)送換成純UNICODE進(jìn)行測試

    朋友催促下，想很快的做出新一版的戰(zhàn)魂，并且添加這4年多來自己所有研究出來的高科技！

    對(duì)于大量的子彈彈幕和高速微操控制，只有幀同步能解決這個(gè)問題，但是中國國內(nèi)對(duì)于幀同步研究的人很少，國外也少見這類文章，甚至用google都很難搜到，難不成是我用錯(cuò)搜索詞？

    大學(xué)時(shí)期曾經(jīng)看過一本重慶大學(xué)出版社出版的游戲編程。基于DX8寫的，很基礎(chǔ)，里面還記得有王鑫寫的幀同步的基本原理。

    這里個(gè)人總結(jié)下：

1. 幀同步，顧名思義：就是每一幀都同步，所以就是真同步
2. 由于數(shù)據(jù)量巨大，一般使用UDP做發(fā)送
3. 要做到數(shù)據(jù)的絕對(duì)同步，延遲不能太大，最好能在局域網(wǎng)來做，延遲20ms以下
4. 如果要在公網(wǎng)傳輸，由于采用的是P2P傳輸，因此，UDP的打洞也是必不可少的

因此，可以先定下采用的網(wǎng)絡(luò)庫是Raknet（http://www.jenkinssoftware.com/），從網(wǎng)上down了一個(gè)下來看視頻，還是很強(qiáng)大的，雖然用的項(xiàng)目不是很多。不過用于個(gè)人的項(xiàng)目已經(jīng)足夠了。

    Raknet和XNA下的網(wǎng)絡(luò)庫很類似，支持可信賴的UDP發(fā)送。由于是自定義的傳輸方式，同時(shí)，沒有TCP的負(fù)載均衡的復(fù)雜算法，因此網(wǎng)絡(luò)傳輸速度可以很快

    在游戲中的幀同步，在我的考慮將是這樣的：

1. 游戲中的邏輯幀與渲染幀是不同步的，邏輯幀也許遠(yuǎn)遠(yuǎn)低于渲染幀
2. 對(duì)于一個(gè)使用elapse值在邏輯控制下移動(dòng)的物體，這個(gè)移動(dòng)算法必須能被時(shí)間插值。
3. 那么我們將這段時(shí)間進(jìn)行分段，每一段就是一幀。我們?yōu)檫@些幀進(jìn)行編號(hào)，類似于封裝TCP協(xié)議一樣。這些編號(hào)更類似于指令號(hào)。
4. 游戲中有一人被作為服務(wù)器使用，每個(gè)玩家將自己的操作編碼成指令后發(fā)送給這臺(tái)服務(wù)器，由服務(wù)器統(tǒng)一分配序號(hào)廣播給所有的其他玩家
5. 對(duì)于可以被時(shí)間插值的動(dòng)畫軌跡（尋路），那么將發(fā)送軌跡（如果尋路算法出來的結(jié)果是唯一的，就只需要發(fā)送起點(diǎn)跟結(jié)尾點(diǎn)）以及每幀更新這個(gè)物體的時(shí)間插值參數(shù)。
6. 由于外界輸入對(duì)系統(tǒng)的干擾，才產(chǎn)生了需要同步的數(shù)據(jù)。外界輸入干擾保護(hù)用戶操作和AI
7. 考慮到每人的網(wǎng)絡(luò)ping值的不同，對(duì)于特別慢的玩家，可能在其廣播指令時(shí)，其他玩家已經(jīng)走出很多步，因此需要計(jì)算一個(gè)平均ping值，當(dāng)網(wǎng)絡(luò)中某人的ping值低于這個(gè)值時(shí)，將彈出類似于魔獸/星際的同步對(duì)話框，等待其本地指令序號(hào)趕上其他玩家的序列號(hào)
8. 由于所有物體的移動(dòng)都可以被時(shí)間插值，因此，游戲中的每一邏輯幀，只需要將本地服務(wù)器在上一幀的ping值和幀號(hào)廣播給所有的玩家
9. 當(dāng)物體啟動(dòng)和結(jié)束移動(dòng)時(shí)廣播
10. 當(dāng)渲染幀數(shù)下降時(shí)，將很明顯的看到幀同步對(duì)象有很明顯的"跳躍"現(xiàn)象，這個(gè)現(xiàn)象在星際中更是明顯。但在技術(shù)成熟的魔獸中已經(jīng)被插值予以替代

    我的項(xiàng)目中由于還沒有加入轉(zhuǎn)發(fā)服務(wù)器，因此暫時(shí)有3臺(tái)對(duì)外服務(wù)器，服務(wù)器與服務(wù)器之間暫時(shí)用內(nèi)網(wǎng)連接，今天將服務(wù)器放到雙網(wǎng)卡的服務(wù)器，發(fā)現(xiàn)竟然將服務(wù)器內(nèi)網(wǎng)地址告訴給客戶端來連接，很明顯這是錯(cuò)的！

    馬上著手解決這個(gè)問題：是否可以根據(jù)配置，對(duì)某幾條連接自動(dòng)從gethostname中獲取到內(nèi)網(wǎng)或者外網(wǎng)地址？事實(shí)證明是錯(cuò)誤的！這里有一個(gè)例子：

    某公司的電話只能對(duì)內(nèi)打，對(duì)外打只能靠私人手機(jī)。如果 A正在用私人手機(jī)跟公司外的B打電話，此時(shí)，B想打C的手機(jī)，但是B不知道C的號(hào)碼。但同時(shí)，A只知道C的內(nèi)線號(hào)，但不知道其手機(jī)。這種情況下，B只有找公司的前臺(tái)D要到 C的手機(jī)號(hào)，因?yàn)锳,C在進(jìn)入公司時(shí)就已經(jīng)注冊(cè)過他們的手機(jī)號(hào)。這樣，B就成功的打通了C的手機(jī)號(hào)。

    這是一種解決方法，也就是說，在現(xiàn)有的服務(wù)器管理的上層，再做一層平臺(tái)服務(wù)器，其他服務(wù)器到這臺(tái)服務(wù)器獲得自己在外網(wǎng)的地址，然后對(duì)需要進(jìn)行外網(wǎng)聯(lián)系的服務(wù)器組和客戶端之間傳輸使用外網(wǎng)地址。

    還有一種方法：

        C首先將自己的手機(jī)號(hào)告訴A，之后B與A聯(lián)系后，得到C的手機(jī)號(hào)，而不是其內(nèi)網(wǎng)號(hào)，即可聯(lián)通

    這種方法的原理就是：將要讓客戶端轉(zhuǎn)接的某臺(tái)服務(wù)器的地址的公網(wǎng)ip保存在配置文件里，在讀取后將這個(gè)地址告訴給列表服務(wù)器，這樣客戶端連過來就會(huì)獲得一個(gè)正確的外網(wǎng)地址

    由于書寫習(xí)慣，現(xiàn)在項(xiàng)目里依然使用我原來習(xí)慣的頭文件定義協(xié)議結(jié)構(gòu)體的方式：

struct EnterLobbyREQ : public ProtocolHeader

{

        char mSessionID[64];

}

這種寫法比較傳統(tǒng)，有以下優(yōu)點(diǎn)：

1. 確實(shí)叫協(xié)議，帶頭文件，如果協(xié)議有修改，客戶端和服務(wù)器代碼馬上能看得出來
2. 可以在結(jié)構(gòu)體里添加一些自動(dòng)填充size,type等的構(gòu)造函數(shù)和一些自動(dòng)計(jì)算變長包大小的函數(shù)，減少拷貝代碼出現(xiàn)的錯(cuò)誤
3. 書寫直觀，初學(xué)者容易理解

但也有以下缺點(diǎn)：

1. 一個(gè)修改可能導(dǎo)致全盤重編
2. 發(fā)送復(fù)雜結(jié)構(gòu)的數(shù)據(jù)不靈活：

   如果只想發(fā)送10-20個(gè)成員的結(jié)構(gòu)體里的7，8個(gè)成員，就需要寫很多的賦值表達(dá)式，而且這樣的代碼充斥整個(gè)工程

    比較流行的寫法就是流式寫包，在有些工程里叫ProtocolComposer

void Foo (ProtocolComposer& composer)

{

        composer << pos << action ;

}

    其優(yōu)點(diǎn)顯而易見：

1. 協(xié)議可以只是一些注釋，客戶端和服務(wù)器只需要約定俗成就可以，修改協(xié)議無需重編
2. 可以在復(fù)雜結(jié)構(gòu)中自由構(gòu)造發(fā)包內(nèi)容，拷貝復(fù)制方便自如
3. 自由制作變長包及類型決定包內(nèi)容種類等

但其缺點(diǎn)也是有的：

1. 一端修改協(xié)議后，另外一端若不及時(shí)修改，在編譯期將無法發(fā)現(xiàn)，如果最后在運(yùn)行期暫時(shí)沒有報(bào)錯(cuò)，將形成bug
2. 組包速度慢于前者，對(duì)C++類型的代碼支持較好，但是c方式接受較為麻煩

總的來說，后者還是為很多項(xiàng)目所用，所以下一個(gè)項(xiàng)目將啟用后者進(jìn)行編寫，希望能得到更好的游戲邏輯編寫體驗(yàn)。如果有更好的建議可以回復(fù)。

    終于拖著8500GT動(dòng)畫片般的將波斯王子4打通。說實(shí)在話，這游戲做的確是好，可惜太卡，居然做夢(mèng)都想買臺(tái)360感覺下。

    波斯王子4繼承刺客信條，依舊是那款命名為"彎刀"的引擎（可以從其打包文件頭看出來）。整個(gè)游戲從一開始到最后，我多被其骨骼動(dòng)畫混合系統(tǒng)驚嘆不已。

游戲中，如果王子先爬上欄桿或者木樁子，公主上來之前，王子自然會(huì)讓開，甚至?xí)斐鲆恢皇掷蟻怼Ａ硗?，協(xié)作動(dòng)畫到處都是，基本上很平滑，不過需要批評(píng)的就是在拉機(jī)關(guān)時(shí)，如果女主角距離很遠(yuǎn)，此刻她會(huì)閃現(xiàn)在機(jī)關(guān)面前

對(duì)比前幾作，本作取消了時(shí)之沙系統(tǒng)，取而代之的是無限制接關(guān)和不死身。很多人抱怨，很多人不滿，但是在我看來，這是對(duì)游戲性的極大擴(kuò)展。時(shí)之沙可以讓時(shí)間倒退，但是用完后還是會(huì)復(fù)位，降低了游戲的流暢感。其實(shí)波斯王子是啥？就是一個(gè)古代跑酷的RPG，相比鏡之邊緣來說，波斯王子的體驗(yàn)感和厚重程度要好很多

值得夸獎(jiǎng)的是本作戰(zhàn)斗系統(tǒng)及人物感覺。前幾作的人都跟紙片貼墻上飛一樣。經(jīng)過刺客信條的洗禮，波斯王子估計(jì)也徹底換了引擎，人物也有厚重感了。戰(zhàn)斗系統(tǒng)的防御及反擊做的極為舒服，只不過重復(fù)的擊打4個(gè)boss有點(diǎn)回到二代的感覺，這就是歐洲游戲和日本游戲的本質(zhì)區(qū)別：策劃和美術(shù)都很懶！

本作的對(duì)話系統(tǒng)很有意思，在你多次掉下懸崖時(shí)，公主會(huì)說："我需要你！你不能死"，王子偶爾抱住公主時(shí)也會(huì)說她長胖了，游戲間，很多感情戲就漸漸的讓玩家感受到了，雖然劇情很俗，但是你卻能體味其中。最有意思的就是公主8分身時(shí)的唯一解法就是跳下懸崖，讓公主來救你，太精妙的設(shè)定了

下一作大猜想：

    想必加入類似于FC版刺殺希特勒的爪子，增強(qiáng)游戲性？

    希望繼續(xù)保持現(xiàn)在的戰(zhàn)斗系統(tǒng)和不死身

    劇情再離奇一些

    至于場景嘛，最好是來個(gè)小時(shí)候看過的 從地里倒長的樹，那可是正宗的阿拉伯故事哦

波斯王子系列歷代都走的是劇情+感動(dòng)+細(xì)節(jié)+語言。

時(shí)之沙，最終女主角死后，主角利用時(shí)之沙之力回到從前，對(duì)過去的女主角說曾經(jīng)有過那么一段情。

武者之心，雖然被達(dá)哈卡追的個(gè)死去活來，但是能在GF4上看到那么唯美的世界已經(jīng)很滿足了，從紅色絲綢的誘惑到最終與時(shí)之女王的纏綿，讓這個(gè)王子不愧為playboy。

王者無雙，從二代劇情延續(xù)過來，但是時(shí)之女王一開始就掛了，之后又回到了初代

而最新作：復(fù)生，講的便是一個(gè)mm和一個(gè)gg一起周游世界打敗黑暗，當(dāng)然，最后mm掛了，因?yàn)樯鼡Q來了光明，gg不肯，把黑暗重新帶回了世界，不過mm活了，私欲啊，私欲啊，o(>﹏<)o