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