前面寫過visual studio c++ 2005中的執行庫的文章，沒想到問題很快就發生了。以前台式電腦使用的是vc2003，還是保留了libcmt，也就是單執行緒靜態庫，大部分小程式也都是鏈結到這個庫下的。剛買了膝上型電腦acer 5573，安裝了乙個vc2005，簡簡單單的跑glut和glew發現有諸多如下問題：
1、glut的命令列和視窗是基於多執行緒的，但是glut庫鏈結的卻是單執行緒。我的程式鏈結到了多執行緒庫，導致，如果先關閉opengl視窗，命令列主線程不會立刻退出，手動關閉後發現返回值有問題，不是0，而是0xc0000001（好像是的）。如果直接關閉命令列，那麼程式會安全的退出，返回0。
2、如果使用了sf.net上提供的預編譯好的庫，使用glsl shader的時候可能會出現問題。當程式退出後，gldetachshader會出現問題，如果你像我一樣把關於shader的撤銷操作都封裝到了類的析構函式中。原因還是庫的問題。
解決的問題很簡單，把vc2005預設的鏈結開關改成/md就沒事了。不過還是有些不放心，畢竟這個執行緒同步問題可真的是要命。
再論3ds模型格式。lib3ds是個很不錯的工具，ogre都用的它。不過我發現為了支援vertex buffer object的渲染方式，還是不得不把資料給抽取出來放到單獨的記憶體區中。我嘗試過stl容器，發現處理速度真的不盡人意，明顯的遲緩，實在多此一舉。除錯了乙個下午還是全部用memcpy搞定了一切。單個模型，所有的頂點資料、紋理座標、索引都與單個obj獨立開來，形成了乙個整體，這樣渲染效率高。不過發現這個向量是個巨大的問題。3ds格式沒有儲存座標資料，而用lib3ds的計算函式計算得到的向量又是不好使用的 —— 它為每個面都計算了3個向量，導致了乙個定點就會有3個向量，可是這可能麼？！我回去再去看看。
很想寫乙個類似於nvidia sdk中的圖形基礎庫放到sf.net上，處理紋理，模型等等。
發現了乙個搞笑的bug，來自nvidia sdk 9.5，如果大夥不相信可是試試。nvidia sdk 9.5提供了許多庫，其中有乙個叫做nv_dds，原始檔有使用方法，就是提供乙個和directx無關的dds紋理讀取處理支援。同樣的，nvidia還有乙個adobe photoshop cs2的dds外掛程式，用來匯出dds格式的紋理。搞笑的是，用nv_dds庫讀取乙個2d with mipmap的dds檔案竟然發現無法識別，除錯的時候發現給識別成了cubemap！？我回學校後再來除錯除錯，對比一下directx sdk自帶的紋理處理工具以及nv提供的命令列工具，看看究竟是不是真的出錯。
買了膝上型電腦感覺也沒有那麼好，反而覺得更忙，天天有看不完的pdf，除錯不完的**。
昨天又跑了一趟女生宿舍幫她們弄路由器，好說待說的讓我進去了。上樓道的時候引來一陣陣詫異。回來的時候舍友說，「我們天天就生活在你的光環下了，你現在人氣實在太高了，反正你也沒有女朋友，就先乾脆整乙個吧」。我無語，實在是無語。
剛剛星期天學了一套恰恰恰銅牌舞步，很簡單的那種，不過踩了女舞伴一下嘿嘿。還是那句話，腳下基本功要紮實。雖然說自負的我很少誇獎別人，不過這次是真的，趙老師真不錯！
生活與工作
很早就想找個真正能自我發洩的地方了，這段時間來過得很不好，應該說是很糟糕.人活著就是為了更好的活著 這句話說出來都知道是什麼意思，也很多人把這樣的句子作為活著的真諦。話到嘴邊說出來很容易，做起來往往都會不近人意，生活的壓力使我們無法擺脫現實的枷鎖，在我們為實現自己一點點夢想而倍加努力的時候，上帝總會...
工作與生活
也許是專案安排不合理，也許是迫於生活的壓力，公司裡外的很多人，似乎已經把加班當做了一種習慣。我並非覺得不應該努力工作，搞it這行，誰沒有過熬夜除錯程式的經歷呢。但如果偶爾的激情變成了習慣的動作，那只是在燃燒自己的生命來換取在別人眼裡或許微不足道的光亮。近期在公司的論壇上看到一位駐阿富汗同事在槍林彈雨...
工作與生活
大學畢業，找了乙份程式猿的工作，分部門時，安排到測試崗位，起初還有些不甘，但是回頭想一想，自己做開發和測試都是一張白紙，為了能快速適應公司，做簡單的測試或許是乙個比較容易的切入點。測試還是開發，哪個職業發展更好，我暫時不去討論，因為我還沒到那個階段。但是不得不說的是，進了it公司，不論是開發還是測試...