2014年1月29日
他猛地把電子書窗口一關，心情久久不能平靜，這簡直就是武林絕學，如果說以前所學只是零零碎碎的招式，這下絕對算大招了!他正在盤算啥時可以耍耍。。。不急！趕緊給同道中人推薦，不過估計他們這會都還在奮筆疾書中。
作者太帥了！招招要害，沒有一句廢話，很對他的胃口。這種人要膜拜下，忽然他想起在某群里似乎有此大名！十幾個群，每個群三四百人，慢慢來。。。
終于，在一個灌水群里，目標出現了，雖然是名字的拼音縮寫，但是對于他這行的人來說，已經足夠標記身份了。但是群里水貨多，這哥們為啥要混這個群？他在想此人會不會像他以前的老大那樣，有一種仰視數學老師的感覺。如果拿圍棋做比喻此人能算幾段？
這哥們似乎不在線，也許還在第一線創作。先看看簽名，說的太TM對了！特別最后那句，程序決定生死，說出了自己的心聲。他要加好友，大俠和高手兩個詞反復挑選，最后選了高手二字做稱呼發了過去。
他忍不住又把電子書打開，再過一遍，感覺寫得太TM好了，其意義簡直是促進人類進步啊！那些花前月下，喝酒吹牛的的人，你們糟蹋了那些文字。
忽然好友申請通過了！高手在線！他毫不猶豫地把那個QQ拖到了“真正高手”好友組。。。
"又改！"對面的那位哥們已經失控了，只見他坦然一笑，好像見過成百上千次似的。他知道，寫這東西，就算寫的再好，碰見外行，也是對牛彈琴。你只要把結果整對，他就閉嘴了。想到這他把最后一個分號打上，一切準確無誤。
"不行，我的意思是這樣這樣"，他有點不高興，剛才明明不是這樣說的，電視里說做人要厚道。但是改起來不麻煩，他賭氣般地找到幾處文字，退格，打字，哦了。
"這邊還要加點東西，要不然太難看了"，他知道電視里說暴躁不好，但是此時明顯有一股無名怒火在燃燒。加上應該就沒事了，應該是最后一次了。他放慢打字速度，喝了點水，用這招來壓制情緒。
正要發起反擊，突然邊上有人喊："你看別人是這樣做的，我覺得他們好NB。"于是。。。他預感一分鐘以后會發生什么。。。他不想那么被動，干脆提前改掉，他要證明我們和他們一樣NB，這樣就清靜了。
電腦鎖屏，安心小解，哼著小曲，輕松愜意。他在想我就不生氣就不生氣。回來路上遠遠看見有人在等他了，他想對方一定會很驚訝怎么這么快就搞定了。。。
"這功能想了一下，還是不要了"，他知道這次他忍不住了。。。
這一夜，他翻來覆去睡不著，黑暗中的天花板越來越清晰。上次出現這情況還是三年前，那時他還是個菜鳥，很多東西似懂非懂。但是這次不一樣，他已經答應了別人，千萬不能搞砸了。
他隱隱約約記得U盤里似乎有他師兄給的一個文件，當時沒看懂直接存在code目錄下了。師兄好像說過這是他熬夜研究出來的東西，發給師弟欣賞下，但是版權要歸他。當他雙擊那個EXE看到里面的畫面之后，對師兄的佩服油然而生，從此暗下決心要像他那樣。
但是師兄好久沒消息了，上次師兄說過覺得累了，不打算繼續干了，兩人的話題也就越來越少了。
他知道，寫這東西是需要靈感的，有時候死磕一天也比不上那靈光一閃！靈光呢?靈光呢？他無法想象明天別人的目光。他對自己說：這一切是不可能發生的！
突然他坐起來了，右手伸向了電源鍵，休眠中的電腦傳來了標準的開機聲音。很快，在他面前出現了新加卷里的那個文件。他飛快地做了個快捷方式，然后切回桌面。
“師兄果然是師兄！”，那一刻他由衷贊嘆卻又思緒萬千，他覺得師兄的選擇太草率了，如果大家都能堅持下來，想切磋就切磋，豈非人生快事！
十分鐘之后，電腦關上了，這回不是休眠，是關機。。。
凌晨3點，在一間狹窄的屋子里，光線昏暗，煙味濃重，一個掛接在機箱外的硬盤不時閃著藍色光芒。靠背椅上坐著一個胡子拉茬，滿眼血絲的人，他披著一件一個多月沒洗的外套，走火入魔般地敲打著鍵盤。“難道是這里？”，他喃喃自語地按下了F5，這一次又要等上半個小時。他習慣性地伸出雙腳往桌子上一搭，忽然想起了剛才在網上和他爭吵的那個菜鳥，“這都不懂？！”，緊繃的臉上露出了詭異的微笑。。。
但是一瞬間他好像感覺到了什么，鼠標拖動一番之后，僵硬的表情凝固了足足十秒鐘。“不可能啊！”他狠狠吸了一口煙，雙手在鍵盤上一陣搗騰，一分鐘，兩分鐘。。。五分鐘，終于緊皺的眉頭慢慢舒展，仿佛一切又回到了他的控制之中。只見他打字越來越快，越來越快，直到戛然而止。。。
原來是QQ消息來了，他有些后悔沒把QQ關了，F-Word脫口而出，顯然他不喜歡三更半夜被別人打斷思路。他瞥了一眼閃爍的頭像，頓時眼冒怒光：這菜鳥還沒搞定嗎？心煩意亂之余他點開了頭像。。。
“大俠，我錯了，搞定了”，他很不耐煩聽到這些，正準備拉黑，消息又響了：“但是我發現還有更好的辦法。。。”一種說不出來的感覺，是憤怒？是好奇？他決定不回消息，看看那菜鳥怎么說。。。
笑了，他笑了，顯然他發現了一個愚蠢的錯誤，于是毫不猶豫的打了幾個字發了過去，那邊是沉默，久久的沉默。他估計菜鳥正在努力理解那幾個字，便切回剛才的窗口，卻想不起剛才寫到哪了。。。
終于打字聲再次響起，他完全沉浸在了自己的世界里，一切都是那么的井然有序，太完美了。激動人心的時刻來到了，他把左手食指停在F5上方，想了幾秒鐘，按下去了！
他閉上眼睛，想象著半個小時之后的喜悅。這時一陣饑餓感突然襲來，晚飯吃過了嗎？現在幾點了？一時想不起來。趁著這會有空他想去找點吃的，但是。。。QQ又響了！
不錯，還是那位菜鳥，還是稱呼他“大俠”，對他豎了一個大拇指。突然他覺得菜鳥不那么煩人，貌似還有點自己若干年前的影子。。。
2012年10月20日
五年前入行就是從Torque Shader Engine開始的,當時的Torque摻雜了若干C語言的實現,架構比較混亂.它的編輯器還算強大,另有一本專門介紹如何用Torque腳本編寫游戲的書,并且還有一個像樣的論壇(VIP用戶要花錢).當時要為它添加一個特效系統,后來發現有一個叫AFX的特效系統是基于Torque開發的可供參考,就花了一個月時間把它移植了過來.再然后就離開Torque陣營加入OGRE陣營.
后來一直陸陸續續地關注著Torque的發展,聽說過它的維護者GarageGames和微軟合作了,搞了個XNA,應該其中包含了Torque的技術(我沒研究過XNA),再后來Torque 3D出現,聲勢浩大,但是要收費,所以沒下也不知道它長啥樣.只是感覺這五年來但凡有印象的大小游戲沒聽說過有用Torque做的,不免讓人遺撼.
這五年以來先后出現了UE3,CE3這種次世代引擎,Torque選擇在這時候開源是明智的(Gamebryo都快撐不住了,OGRE就更別說了),它可以做為一款比較適合入門的引擎.它的技術經過這么多年這么多人的發展肯定也有可取之處(當年還贊嘆它能把OGL和D3D統一起來),所以既然開源了沒有不下的道理.架構一定要看下,希望不要再讓人糾結了.
2010年7月25日
在某些情況下需要做網格的輪廓檢測,例如ShadowVolume,勾邊渲染等,具體算法如下:
假設參考邊為uv,u和v是兩個端點所有共享邊uv的面集合記為sides,則:
1.遍歷網格的索引緩存,對每條邊構建sides;
2.對每個sides集合,檢查dot(normal(side[i]),view),view是視線方向,如果結果中有正有負,則該邊為輪廓邊,將輪廓邊加入一個圖結構graph;
3.在graph中使用深度優先算法檢測回環,如果有回環就是輪廓.
2010年7月14日
減面算法一般分減點和減邊兩種,前者減一點會影響好幾個面,網格形狀變化會比較大,所以研究后者比較有意義,一種參考算法如下:
假設參考邊為uv,u和v是兩個端點,所有共享點u的面集合記為faces,所有共享邊uv的面集合記為sides,則cos(u,v)=max(min(dot(face[i].normal,sides[j].normal)))*length(uv).
2007年7月7日
接觸極限編程一段時間，找到以下四點反駁它的理由：
[1]代碼質量
極限編程運用測試驅動開發（TDD），其理論基礎是需求應該是可測試的，其目的在于保證軟件系統的正確性和健壯性（測試用例足夠充分的話）。可以這么認為：極限編程關心的是結果，不關心過程。因此它忽略了軟件系統的結構性和開放性。我們知道結構性有助于修改，開放性有助于擴展，而極限編程卻放棄這種追求，導致的結果就是產生一大堆丑陋的代碼，而且隨時有可能被徹底拋棄。
極限編程解決效率，結構性和開放性問題的對策是重構，它宣稱重構無處不在，但是重構是一種補救的方式，為什么不在設計初期進行預防呢？極限編程回避不了這些問題，而只是將它們推到了后面的階段，但是付出的代價可能會更高。
[2]工作進度
極限編程直接將代碼作為文檔，弱化傳統文檔的作用。既然如此，那么代碼就應該有規范的格式和詳盡的注釋，以便提高它的可讀性，但是由于極限編程采用的是團隊合作方式，代碼規范很難得到統一。那么通過注釋吧，可是極限編程認為注釋是一種負擔，無法適應頻繁修改的代碼。
極限編程解決溝通問題的對策是結對編程，它認為頻繁的溝通勝過面面俱到的文檔，但是文檔是永久的，溝通卻是短暫的，大家可以看同一份文檔，卻要進行多次兩兩溝通，所需時間也許并不比寫文檔的時間少。更糟糕的是，經常地切換搭檔將極大地破壞工作的延續性，只能拖慢進度。
[3]工作量
測試驅動開發具體應該怎么做呢？測試驅動決不是說代碼從測試寫起，在寫測試用例之前，肯定要對需求有完整的了解，否則測試無從寫起，其實這就是需求分析以及設計，還是與瀑布模型一樣的流程，只不過沒有文檔化而已。唯一不同的是極限編程要求需求都是可測試的，因此要把這些需求翻譯成系統測試用例，集成測試用例，和單元測試用例。由于寫程序必須同時寫它的測試，因此如果改程序則必須改測試，這將達到兩倍的工作量。
[4]目的
極限編程認為需求是不斷變化的，因此軟件能滿足當前需求就好，沒有必要構造框架之類可復用的東西，它認為這是一種過度設計。這種思想是極端的，因為框架就是為了解決需求變化問題而出現的。舉個例子，MFC就是一套框架（盡管我厭惡它），但是基于MFC卻可以開發網絡，多媒體，數據庫甚至游戲應用程序。面向對象的目的就是為了復用，而且好的框架能夠做到隔離變化，依賴抽象，如果認為軟件系統的一切東西都是暫時的，無疑是與面向對象思想背道而馳的。
2006年10月20日
??? 說來慚愧，學了這么久的圖形學，今天才動手編了自己的第一個Cg程序，參考的就是那本《The Cg Tutorial》。Cg的GPU概念徹底改變了我對圖形學的看法，傳統的程序都是由CPU執行的，這種觀念在其它方向的程序員看來天經地義，但是對于圖形程序員來說，從2002年Cg誕生開始就已經顛覆了。面向GPU編程，讓CPU解放出來，能夠極大地提高了渲染速度。還有，它實現了可編程的渲染，對于游戲來說，就意味著能夠以腳本的形式來渲染場景了，如果再配合那些AI腳本，游戲引擎基本上就能夠建立在腳本之上了！大部分的C++程序員都會對Cg有種似曾相識的感覺，因為它是面向圖形的C語言，配置和編程都很符合習慣。對于使用DirectX的游戲程序員來說，Cg與HLSL其實上同一種語言。我個人認為DirectX的所有組件其實都可以使用別的工具代替，而Cg則是其中最高級的替代品，決定用它了。
2006年9月28日
??????? 畢業論文的初稿已經出來了，暫時可以先喘一口氣，我做的是《射擊類三維游戲引擎》，總的感覺是“麻雀雖小，五臟倶全”。我將引擎分成了七塊：界面包、資源包、設備包、實體包、實用包、工具包和一個程序框架。界面包負責顯示視圖，資源包負責調度資源，設備包負責虛擬設備，實體包管理游戲中有意義的實體，實用包包括物理系統、效果系統、媒體系統和腳本系統，工具包包含一些數學和圖形學的數據結構，程序框架采用Windows的消息驅動和消息映射機制。體系結構比較清晰，但是技術含量還有待提高。當前主流的游戲引擎都支持圖形兩套引擎（OpenGL和Direct3D）以及一門高級渲染語言Cg，而我的引擎只用了OpenGL，只能感嘆自己學藝不精。圖形學方面從來就不缺牛人，而且很多都是從數學轉過來的，不過我也是從數學科班出身，也許幾年之后...不管那么多，向人家取經吧。