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