// 接受密聊對方名稱,將焦點設置到聊天輸入框中,并且將光標設置為第一個位置
// 參數1:密聊用戶名,參數2:頻道信息
static bool ChangeChannelAndSetFocus(char* username,Channel channel);
這段代碼看起來是沒有事情的,但是在接口設置上面存在不好的做法,如果是私密頻道的話,是有用username做私聊對象的,如果是非私聊頻道的話,就沒有這個私聊對象了.但是如果要調用這個接口的話,還得給個這樣的值.
比如這樣的用法:->ChangeChannelAndSetFocus("",public_channel),
其實如果稍微改變一下接口設置的話,就好了.
static bool ChangeChannelAndSetFocus(Channel channelchar* username = "");
這樣使用默認參數就好了.
之前的調用就可以這樣使用了.
:->ChangeChannelAndSetFocus(public_channel),看起來舒服多了.哎感覺編程功底還有待加強,這么簡單的問題,拿出來想想,還有這么多學問呢.
這幾天寫了一段函數代碼,后來被一個家伙調用了,他直接在我的函數里面修改,這樣造成了原來我函數里面的邏輯出現錯誤,現在想來,如果以后是這樣的情況,就不能允許他在我的函數里面修改我的邏輯和相關調用,但是要留出接口給它調用,至于具體的操作,要我自己允許才能添加,當然我可以幫他看看原來他添加的代碼,但是這樣也就沒有什么意義了.這種合作性的工作尤其要講究這些,不然很麻煩的.
突然想起來要記錄點什么,調試引擎的時候,可以采用這樣的方式,打開上層邏輯的工程,然后將引擎相關的代碼拖拽到上層邏輯所在的工程里面去,然后在這個代碼里面可以設置相關斷點,以前總不知道怎么找上層邏輯與底層引擎的入口,最近終于知道了.呵呵.通過這樣的方法,就可以在上層邏輯做某些操作,然后關聯這些邏輯相關的引擎代碼.
今天一直在被單態困擾著,事情是這樣的:大廳和戰斗場景里面都有兩個類似的chatroom,并且他們各自使用的協議是不一樣的.現在想把他合并起來做成類似singleton的東西. 之前就遇到一個問題，大廳和戰斗場景不能在相互之間發送信息，后來我的處理方法是將戰斗場景里面添加大廳里面的響應事件，這樣的話，在大廳里面發送私聊信息到戰斗場景里面，就可以接受到了，但是后來發現在戰斗場景里面發送信息到大廳里面，卻接受不到，并且這個時候，在大廳和戰斗場景里面已經存在很多冗余代碼了，這樣的處理讓我感覺很不爽，我在想有沒有其它辦法，后來請教了老大，老大幫忙解釋了一下，后來，在協議處理方式上面修改了一下，才可以的。chatroom在不同的時候發送不同的協議就好了，并且在接受的時候分開大廳和戰斗場景處理就好了，這樣還是用了接受、和發送這兩段廢代碼。對于singleton的了解還是不夠好。
之前遇到的問題，是聊天發送消息并不立即顯示在本地，而要先將信息轉到服務端，服務端進行查詢，如果能夠找到這個私聊對象，那么就返回給信息，否則就顯示說該用戶不存在，在戰斗場景里面向大廳的某個玩家發送私聊信息以后，退出戰斗場景以后，發現大廳里面還顯示著在戰斗場景里面發送的聊天信息。這樣即使我按照常規思路去把網絡接受端的相關代碼注釋掉也不能達到消除大廳里面的聊天信息的目的，感覺很郁悶。后來查看私聊信息方面的代碼，發現沒有將信息有效地攔截，私聊信息在本地上面還可以被顯示，沒有經過網絡方面的驗證就直接發送過來了。在私聊信息方面做一些處理并且在退出戰斗場景的時候做一些信息刪除處理，這樣就可以達到目的了。
因為玩家對象位置數據是從服務器那邊發送過來的,玩家從服務器獲得數據需要一段時間,所以需要加入一個插值,來將現在的位置過渡到下一個的位置.這里可以采用多種插值方法.
今天寫了代碼去改寫強制動作的處理，結果發現很多處是有問題的，其中原因是沒有將原來的代碼作用看仔細造成了，感到羞愧呢，
另外在編寫交互性比較強的代碼時，一定要考慮自己的代碼可能帶來的影響。
更新某個文件比較麻煩的話,那么可以先采用原始文件刪除,并且重新全部更新的做法去做,而不是用更新某個字段的方法去做.
如果沒有初始化聲音設備成功的話,那么應該可以彈出提示信息框,并且將原始聲音音量設置為0.
之前在修改一個bug(在人物控制面板打開以后,一直克隆object,造成了在引擎底層無法鎖定vertexBuffer的問題),開始以為是內存泄露了,在打開控制面板10分鐘以后,游戲就突然出錯了,還一度想用一些輔助工具來查找內存的信息是否出錯,后來發現在人物控制面板里面克隆了過多的人物object,而這些object卻沒有及時地刪除,造成占用過多的資源,到最后連鎖住vertex buffer也不行了.在分析這個問題上面的時候,我還是一個勁地挖底層而沒有考慮太多的邏輯層面的東西,實在有點南轅北轍的味道.值得反省.
在輸入的使用上面,一般的游戲都采用directInput,即使是U2,上次遇到的問題是,在一同事機器上面運行輸入的時候就進入不了,但是在別人的機器上面卻可以運行好好的,后來經常查訪發現:1)用配置文件寫入的,之后再綁定到某個特定鍵的快捷鍵都不能用,因為這些是讀入內存以后,然后用add_binding來綁定到directInput設備上面的,2) 在游戲里面使用windows message的卻可以正常使用.進入游戲的時候,你不能輸入,而只能回車,按tab鍵以后,就可以在登陸界面輸入,如果不能按tab鍵,則不能輸入,進入游戲以后卻可以按不是從配置文件里面讀取的信息,比如技能,人物面板,倉庫,以及地圖等.
其中我個人建議是,盡量不要用directInput.1)首先是directInput依賴于機器,如果機器好的話,那么沒事情,如果有事情的話,那么也很難解決,2)directInput里面采用了hook,來攔截消息,這樣,還不如直接用windows message來的快?
http://www.gamedev.net/community/forums/topic.asp?topic_id=520366詳細的討論見上面.
在調試邏輯沒有發現什么錯誤提示的時候,試著去調試引擎,可能問題發生得更加深,不在邏輯層面上,而在引擎內部,這樣就要直接調試引擎了.
在涉及到渲染方面的bug,盡量借用d3ddebugging來輔助查錯.這樣可以方便解決問題.
連接錯誤：IID_IDirectSound3DBuffer，其實加上dxguid.lib就好了。
紋理尋址模式包括：
wrap, border color, clamp,和mirror以及mirror once.
pDrawPrimInternal->SetTexture(hTex);
之前遇到的一個問題是，顯示玩家在小地圖上面到地圖邊界了，還能重復繪制地圖，給人的感覺好像是走不到邊界，走地圖好像是在卷軸里面一樣。
后來才知道一般默認的紋理尋址模式是wrap方式。
get_device()->SetSamplerState(0,D3DSAMP_BORDERCOLOR,0x00ffffff);
get_device()->SetSamplerState(0, D3DSAMP_ADDRESSU, D3DTADDRESS_BORDER);
get_device()->SetSamplerState(0, D3DSAMP_ADDRESSV, D3DTADDRESS_BORDER);
解決bug有時候不如重寫
盡量讓策劃去管理邏輯，邏輯程序員盡量將重心放在具體技術問題上面，不懂的地方應該主動跟策劃溝通，而不是自己想。
代碼可以先模擬出來，然后再放到具體的環境里面測試，獨立寫個demo之后再去測試，這樣往往會比較快捷和省事情。
學會模擬機器執行代碼的次序，并且提高閱讀代碼的問題，之前的時候，我使勁去調試，每次調試只為了解決一個問題，但是事實上，如果從閱讀代碼開始的話，那么我可以省掉1天的時間。
學會調節編寫代碼時候的心情和心態，這樣有助于進行高效編程，當心情不好的時候，一定要集中全部的注意力，并且將思路和流程作出圖記載在紙上面，這樣可以強迫自己全神貫注。
今天遇到的文件打開問題是文件名路徑有空格造成的，值得指出的是對于文件打開報錯，一般很難獲得返回值信息，但是可以通過GetLastError或者@Err,以及hr等來獲得一些錯誤返回值信息。
對字符串操作，盡量要檢查是否有空格，如果字符串長度前面有空格的話，那么將被認為所提供的字符串是空的。要避免這種情況的發生。對于字符串匹配要注意部分匹配的情況，比如"Tex", "Text",這里如果只匹配前面三個字符的話，那么兩者是相等的，之前就遇到一個這樣的問題，就是texture的信息被text信息所覆蓋了，導致控件找不到正確的texture而不能顯示出來。
今天遇到的問題是這樣的，之前遇到的狀態切換問題，是與狀態切換無關，而與插值有關，在切換狀態以后，收到一個插值位置，這樣又給角色一個新的位置，給別人看的效果就是角色先落地了，之后又上升了，像坐電梯一樣。不過從這里說明了一個問題:我在思考問題的時候，有欠周全的因素。
今天跟蹤一個bug,在戰斗的時候，出現卡死的情況，后來發現狀態切換出現了問題，后來一直去查看戰斗方面的狀態，但是還沒有發現什么結果，現在在想在戰斗中的標志或者狀態的時候應該設立一些標志集合，這樣便于在某個時候檢查一些狀態的信息。現在很多的標志在游戲里面，局部的，全局的，標志在角色上面的，標志在物體上面的，這些都需要好好地管理。
全方面,多角度地思考問題,而不能將思維局限在某處.學會從大局或者小處去分析問題,大處不行的話,就小處,將相關的信息串起來.所有的信息應該是個串型或者鏈型的.之前在處理問題的時候,把思路限制在太小的范圍內了.以至于花了很多時間才找到問題所在.
根據正常情況和非正常情況來獲得數據比較，以確定正確的流程和結構。如果遇到錯誤的亂值，那么就看看正常的數值，然后根據這個比較來獲得一些提示信息。
今天犯了錯誤，自己有最新版本，但是沒有上傳，結果vss上面的版本把自己的最新版本給覆蓋了。
在發送消息的時候，有時候為了防止頻繁發送消息，要加入一個cd時間，防止因為網絡問題，服務端收到玩家連續的信息。
物理系統, v = v0 - gt. 玩家上跳的速度表示,而在下降,則是v = gt,按照自由落體運動來進行.并且速度是個向量,這樣如果在X,Z軸上面有初速度的話,那么就可能出現拋物線的情況.