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