用windows live客戶端發(fā)。。。或者先在其他地方寫(xiě)好，發(fā)的時(shí)候粘貼過(guò)來(lái)
re: 根據(jù)子類類型訪問(wèn)其特有操作 Kevin Lynx 2011-02-25 14:53
我覺(jué)得就為了歸納一些共同接口，這樣子做有點(diǎn)過(guò)了。不妨考慮在類設(shè)計(jì)時(shí)就將功能分出來(lái)。與其想盡辦法保持類接口的數(shù)量不膨脹，倒不如讓類的功能單一。簡(jiǎn)單的繼承結(jié)構(gòu)就夠了。
re: 寫(xiě)程序真他媽爽啊 Kevin Lynx 2011-02-25 09:05
純表
re: 綠色免費(fèi)記單詞軟件-語(yǔ)言島 Kevin Lynx 2011-02-23 13:08
ubuntu10.04無(wú)法運(yùn)行
堅(jiān)持看完了，感覺(jué)講到DSL的時(shí)候就嘎然而止了。總的來(lái)說(shuō)作者寫(xiě)的不錯(cuò)。讓我也想去學(xué)學(xué)lisp
re: 初學(xué)java（一） Kevin Lynx 2011-01-24 10:00
@あ維wêiセ
cppblog首頁(yè)推薦內(nèi)容需要博客作者對(duì)內(nèi)容自我斟酌 :)
re: 我的游戲編程之路（一）[未登錄](méi) kevin lynx 2011-01-17 09:39
@戰(zhàn)魂小筑
:) 金點(diǎn)工作室。。。
LS兩位都算是這行的元老了。
re: 代碼自動(dòng)生成-宏遞歸思想 Kevin Lynx 2011-01-13 09:10
@溪流
從原理上來(lái)看的話，我們最終需要的是各種帶有1、2、3之類的相似符號(hào)，例如 typename P1,typename P2,....，所以，逐步拆分這些符號(hào)后，就會(huì)自然而然地得到”基礎(chǔ)數(shù)字序列生成器”：DEC。
相當(dāng)于，DEC系列宏就是這個(gè)宏庫(kù)的基礎(chǔ)，而PARAM_1則算是稍微上層一點(diǎn)的應(yīng)用。
ps，很久沒(méi)搗鼓這些復(fù)雜的東西，諸多遺忘，見(jiàn)諒。
同感。經(jīng)常看到領(lǐng)導(dǎo)說(shuō)某某交流有問(wèn)題，但是這個(gè)某某恰好是埋頭做事情的人。比只說(shuō)不做的人好多了。
恩。果然是20-30塊錢(qián)一頁(yè)。。。
- -| 我也收到這個(gè)留言了。。。不過(guò)討論的還沒(méi)LZ細(xì)。
re: 惡心的轉(zhuǎn)載 Kevin Lynx 2010-12-24 09:00
話說(shuō)整理書(shū)上的內(nèi)容，算不上多大的原創(chuàng)吧？包括這個(gè)“讓CPU占用率XX”我以前同事也寫(xiě)過(guò)類似的。。。
http://www.shnenglu.com/Fox/archive/2008/04/17/control_cpu_using_curve.html我的BLOG也四處被轉(zhuǎn)載，但是并不打算去追究，別人用不商用，就當(dāng)傳播知識(shí)。
re: [譯文]VIM使用者大腦的形態(tài) Kevin Lynx 2010-12-23 09:14
手不離開(kāi)主鍵盤(pán)的感覺(jué)很好。
re: 軟件開(kāi)源很重要嗎? Kevin Lynx 2010-09-21 15:34
貢獻(xiàn)你的知識(shí)影響別人也算是對(duì)于自己曾經(jīng)在網(wǎng)絡(luò)上獲取免費(fèi)知識(shí)的一種回報(bào)。但是，開(kāi)與不開(kāi)全看個(gè)人，罵人的就不對(duì)了。
基本上不會(huì)有人在游戲邏輯線程里放置IO操作的代碼吧，包括網(wǎng)絡(luò)和DB。對(duì)于玩家的重要操作有時(shí)候需要立即存儲(chǔ)。
re: 劍3資源格式分析（一） Kevin Lynx 2010-07-16 13:45
@johndragon
這種東西。最好聲明一下，“本文僅用作學(xué)習(xí)” - -
re: 游戲資源包簡(jiǎn)單設(shè)計(jì) Kevin Lynx 2010-07-09 09:26
@大蝦
把文件內(nèi)容直接替換了，然后修改file_tag
re: 關(guān)于C++之“復(fù)雜” Kevin Lynx 2010-07-07 13:45
此帖必火。最后很可能成為又一輪語(yǔ)言大戰(zhàn)。
我以前是C++/OO的狂熱者，后來(lái)有變得不狂熱。其他語(yǔ)言我熟的不多，就拿C做比較。
1、語(yǔ)法相對(duì)復(fù)雜，語(yǔ)法規(guī)則細(xì)節(jié)太多，越是懂得語(yǔ)法細(xì)節(jié)越多，寫(xiě)出的代碼越是往復(fù)雜方向靠。記得我以前寫(xiě)過(guò)一篇牢騷貼（強(qiáng)大的BCB），那個(gè)移植我的C++代碼到BCB編譯器時(shí)所經(jīng)歷的編譯除錯(cuò)，就整出了很多語(yǔ)法細(xì)節(jié)。尤其是參雜了模板的C++。我想，就我以前在C++上的努力而言，不算不懂亂說(shuō)的人吧
2、帶來(lái)的設(shè)計(jì)復(fù)雜，基本上C++會(huì)被捆綁到OO上，見(jiàn)到的C++庫(kù)越多，了解的設(shè)計(jì)思想越多，自己做的設(shè)計(jì)也越來(lái)越傾向于復(fù)雜，我們的代碼是否真的會(huì)面臨這些變化？相比而言，在用C寫(xiě)庫(kù)代碼時(shí)，就非常直接，接口設(shè)計(jì)方式也很簡(jiǎn)單。
re: 造輪子我的觀點(diǎn)，附一則求職信息 Kevin Lynx 2010-07-07 09:18
@zuhd
老實(shí)說(shuō)是二流本科的不才女。。。
re: 多線程還是單線程？ Kevin Lynx 2010-07-06 11:58
@tanxw
AI單獨(dú)到一個(gè)進(jìn)程里，這些邏輯模塊之間又涉及到線程同步問(wèn)題了。
@浩毛
對(duì)于只有游戲邏輯和網(wǎng)絡(luò)IO的進(jìn)程而言，你說(shuō)的只開(kāi)一個(gè)線程，似乎也在理。不過(guò)由于網(wǎng)絡(luò)IO這塊情況可能比理論上要復(fù)雜很多，例如實(shí)際使用的網(wǎng)絡(luò)IO機(jī)制（IOCP）、網(wǎng)絡(luò)層數(shù)據(jù)的拷貝、封包組建等，似乎保險(xiǎn)的做法還是開(kāi)多個(gè)線程來(lái)做。何況，邏輯線程可能還會(huì)涉及到限幀問(wèn)題。拿去運(yùn)營(yíng)的服務(wù)器一般也是多核的。LINUX下線程實(shí)現(xiàn)的效率如果真的太那個(gè)啥，或者可以考慮多進(jìn)程的結(jié)構(gòu)(網(wǎng)絡(luò)模塊和邏輯模塊位于不同進(jìn)程)。
re: 造輪子我的觀點(diǎn)，附一則求職信息 Kevin Lynx 2010-07-05 18:12
@陳梓瀚(vczh)
看到MS字母組合，我們果斷自卑了。。。- -|
re: 造輪子我的觀點(diǎn)，附一則求職信息 Kevin Lynx 2010-07-05 17:05
@ccsdu2009
沒(méi)多大要求，蓋老板給個(gè)稀飯錢(qián)就知足了 :D
re: 網(wǎng)游中的玩家移動(dòng) Kevin Lynx 2010-06-23 09:39
@keror
這里返回的消息，客戶端僅用于遞減請(qǐng)求計(jì)數(shù)。不會(huì)立即影響客戶端的移動(dòng)效果。
re: 網(wǎng)游中的玩家移動(dòng) Kevin Lynx 2010-06-23 08:52
@evoup
話說(shuō)你沒(méi)有看清楚我說(shuō)的內(nèi)容。每一步發(fā)的消息僅用于服務(wù)器的驗(yàn)證，不同步客戶端數(shù)據(jù)。
@小時(shí)候可靚了
這個(gè)屬于另一個(gè)話題了，客戶端會(huì)粗略估算其他角色的移動(dòng)情況，如取得方向模擬其行走，以達(dá)到自然的效果，改天細(xì)談下。
re: 游戲資源包簡(jiǎn)單設(shè)計(jì) Kevin Lynx 2010-06-21 11:36
@飯中淹
對(duì)啊，好方法。移動(dòng)分配表的代價(jià)比移動(dòng)文件內(nèi)容小多了。不錯(cuò)。
re: 求解：編譯順序問(wèn)題 Kevin Lynx 2010-06-12 09:02
個(gè)人覺(jué)得這種情況，就設(shè)計(jì)感覺(jué)上來(lái)說(shuō)就不好。互相耦合。單就這個(gè)情況來(lái)看，可以把類型抽離到一個(gè)公共文件里。如果是對(duì)類本身的依賴，當(dāng)然可以使用前置聲明。
這個(gè)應(yīng)該是在處理類定義之前，發(fā)現(xiàn)了同名的宏，導(dǎo)致在編譯之前（預(yù)處理階段）把類成員當(dāng)作宏做了宏體的替換。LZ說(shuō)法欠妥:)
re: 不懂那么多人為什么要做游戲引擎 Kevin Lynx 2010-05-29 12:49
這個(gè)標(biāo)題。我感覺(jué)LZ在說(shuō)自己。- -!
re: 令人氣憤的現(xiàn)象 Kevin Lynx 2010-05-28 08:45
表示，這種人太多，無(wú)視了。
我覺(jué)得完全可以忽略子對(duì)象（成員變量對(duì)象）的細(xì)節(jié)，也就是說(shuō)假設(shè)這里的內(nèi)存池只管理player，那么你就沒(méi)必要去理會(huì)這些容器底層的細(xì)節(jié)。因?yàn)檫@會(huì)成為一個(gè)遞歸的情況。
如果僅僅是為了緩存player本身，最好還是在將player放回池中的時(shí)候，來(lái)次reset吧。不然下一次再取出來(lái)的時(shí)候，會(huì)得到一個(gè)并非處于initial狀態(tài)的對(duì)象，這會(huì)增加邏輯的負(fù)擔(dān)。
汗。。- - 。。偶然間看到LZ 博客HGE一欄居然轉(zhuǎn)載有我N久以前亂寫(xiě)的東西，真巧啊。。
@小時(shí)候可靚了
剛想補(bǔ)上這句，差距都是12.。。- -
我這邊差距都是4，正常差距，但是順序詭異。。。
@小時(shí)候可靚了
0x0012ff60 a
0x0012ff54 p
0x0012ff48 i ？？？
如果是這樣的話，那這個(gè)才是正確的排列地址啊。詭異的是我那個(gè)情況。
@小時(shí)候可靚了
飯給的解釋是我在群里跟他談過(guò)的。
這個(gè)解釋是我在看匯編的時(shí)候看到的：
00401750 push ebp
00401751 mov ebp,esp
00401753 sub esp,0Ch
00401756 lea eax,[ebp+4]
00401759 mov dword ptr [p],eax
恰好a莫名其妙地出現(xiàn)在棧頂，而不是p，（而在我舉的包含i的例子中，作為出現(xiàn)在最后定義的i卻莫名其妙地出現(xiàn)在棧頂），加上這個(gè)push ebp，就出現(xiàn)了3。
誰(shuí)能給個(gè)解釋：為什么a、p、i三者的相對(duì)地址和其定義順序存在差別？（難道編譯器對(duì)數(shù)組的處理要特殊點(diǎn)？）
@小時(shí)候可靚了
這個(gè)不需要你重申，我更不希望我來(lái)重申我的問(wèn)題：
解釋下這個(gè)：
int a[1];
int *p;
int i;
a : 0x0012ff74
&p:0x0012ff78
&i:0x0012ff70
注意p在中間 。
@壞
需要適當(dāng)調(diào)整 3 這個(gè)偏移量
ps,當(dāng)然也取決于編譯器生成的指令。鑒于目前我也不明白為什么偏移是3，看起來(lái)LZ也無(wú)法給出詳細(xì)的說(shuō)明，這個(gè)3很有可能只是個(gè)巧合。
1、除了push ebp外可能還有壓入其他寄存器的值（保存寄存器信息）
2、a理論上應(yīng)該不在棧頂，就像我例子中的i，而p應(yīng)該在棧頂
@小時(shí)候可靚了
{
int a;
int b;
int c;
}
按我的理解，c應(yīng)該在棧頂，而不是a。但是實(shí)際上跟蹤你的代碼來(lái)看，a確實(shí)在棧頂，在p后添加變量int i ，又有意外：
a : 0x0012ff74
&p:0x0012ff78
&i:0x0012ff70
@小時(shí)候可靚了
a 的地址是 ebp -8
p 的地址是 ebp-4
這兩個(gè)結(jié)論從何而來(lái)？何況，為什么要+3？
ps，話說(shuō)這樣N多回復(fù)會(huì)給你BLOG增加不少積分啊 :D
@小時(shí)候可靚了
我說(shuō)的是有點(diǎn)問(wèn)題。跟參數(shù)沒(méi)關(guān)系。參數(shù)先于返回地址壓棧。- - 昏頭了。
話說(shuō)回來(lái)，仔細(xì)分析的話，我突然發(fā)覺(jué)：
int* p = (int*)&a[0]+3;
這里為什么會(huì)是3呢？跟了下匯編，發(fā)覺(jué)直接被翻譯為ebp+4了:
push ebp
mov ebp, esp
...
mov eax, [ebp+4]
不是很明白這個(gè)地方。
飯老大說(shuō)得和我一樣。
這個(gè)可以從call和ret指令所做的事情來(lái)看，更涉及到函數(shù)調(diào)用在編譯器以及目標(biāo)機(jī)器指令問(wèn)題。不過(guò)因?yàn)檫@里不存在虛擬機(jī)問(wèn)題，都是x86，也就只針對(duì)call和ret而言：
不難想象在main之前的地方有如下代碼：
; 壓參數(shù)
push xxx
push xxx
push xxx
call main
;main
xxx
xxx
ret
首先call的動(dòng)作主要包括：先壓入返回地址到堆棧上（ebp指向），而c函數(shù)中，函數(shù)負(fù)責(zé)堆棧平衡，那么main中清除局部變量，改變ebp后，可以肯定ebp指向的當(dāng)前堆棧中的值就是返回地址。ret指令則是從棧頂取出該地址并執(zhí)行PC寄存器的跳轉(zhuǎn)。
另一方面，函數(shù)調(diào)用時(shí)的運(yùn)行時(shí)堆棧問(wèn)題：首先棧是向下增長(zhǎng)的，函數(shù)A調(diào)用函數(shù)B，那么首先壓入?yún)?shù)到棧中，在函數(shù)B中因?yàn)榫植孔兞康脑鲩L(zhǎng)棧繼續(xù)向下增長(zhǎng)，也就是說(shuō)，最終可以通過(guò)ebp的偏移取得函數(shù)A中局部變量的信息。他們貢獻(xiàn)同一個(gè)棧：
--stack--
A:local_var1
A:local_var2
A:ret_addr
B:arg_var1
B:arg_var2
B:local_var1
....
基于以上兩個(gè)條件，指針a[0]+3，則向高地址偏移了12字節(jié)的地址（3*sizeof(int)），看下main函數(shù)的參數(shù)，實(shí)際上是3個(gè)：argc, argv, env。這樣偏移后，恰好就是調(diào)用main那個(gè)函數(shù)在使用call時(shí)，壓入的返回地址。
因此，在main返回時(shí)，ret彈出的地址已經(jīng)被改變。
ps:
在錯(cuò)誤地跳轉(zhuǎn)到test后，test執(zhí)行完去ret時(shí)，堆棧上提供的返回地址是不定的，崩潰也很正常了。
其實(shí)沒(méi)必要考慮到這么復(fù)雜，關(guān)鍵在于要認(rèn)清指針在這里表現(xiàn)出來(lái)的語(yǔ)法特性：
指針同普通變量一樣，在函數(shù)內(nèi)部的指針定義就是一個(gè)簡(jiǎn)單的局部變量：
main()
{
int *p ; // 可以簡(jiǎn)單理解為一個(gè)類型為int*的變量
}
C語(yǔ)言里的函數(shù)調(diào)用按值傳遞，所以：
void func( int *p );
func( p ); // 把變量p的值復(fù)制過(guò)去，跟p本身沒(méi)有關(guān)系
void func( int *p )
{
}
函數(shù)參數(shù)依然被存儲(chǔ)于函數(shù)局部棧里，何況，這里的實(shí)參p，按照我這里說(shuō)的語(yǔ)法規(guī)則，只不過(guò)是main里p的拷貝，這就如同：
main()
{
int p ; // p是一個(gè)int類型的變量
func( p ); // 復(fù)制p的值給func的實(shí)參
}
func( int p )
{
}
當(dāng)然，一睹匯編代碼，也確實(shí)能認(rèn)清真相。不過(guò)我覺(jué)得，既要從本質(zhì)去看，也要從規(guī)則去看。這里的規(guī)則我主要指的是語(yǔ)言帶給我們的整體語(yǔ)法感覺(jué)。恩，這個(gè)說(shuō)不清了。
re: 某內(nèi)存池中的指針用法 Kevin Lynx 2010-05-04 17:44
就是把一整塊內(nèi)存分成多塊，利用未使用位置串聯(lián)下這些塊。很多代碼都會(huì)涉及到這種用法。
re: gc庫(kù)概念簡(jiǎn)化版 Kevin Lynx 2010-04-30 10:23
每一次調(diào)用gc_collect的時(shí)候，s_color變?yōu)閷?duì)立值（0->1, 1->0)，然后gc_mark_r將位于s_links中的指針全部標(biāo)記為當(dāng)前的s_color值，那么在gc_collect之前gc_unlink的指針依然為原來(lái)的s_color，即未被標(biāo)記，然后gc_collect回收這些未被標(biāo)記的指針（指向的內(nèi)存）。
不是很明白，s_linkClean在這里的作用。
re: gc庫(kù)概念簡(jiǎn)化版 Kevin Lynx 2010-04-30 09:42
- - 果然需要自己“改改才能編譯過(guò)去”。。