其他

http://developer.amd.com/wordpress/media/2013/04/DX11PerformanceReloaded.ppsxnv和amd共同呈現的一個dx11上面硬體最佳化方面的資訊，非常棒的底層知識的介紹，不僅僅是dx11，dx9的開發人員也會受益良多。裡面很多知識在其他地方也提到過，不過或是學習新的東西，或是複習已有的知識，開卷有益吧。運行時刻shader的asm會被編譯成ISA機器彙編，才能被運行，這個過程會消耗一定cpu運算，造成卡頓，那麼提前把需要的sha

<GPUPro>裡面的一個文章，講spore的可以用指令碼驅動的filter chain。spore是一個有鮮明特點的遊戲，那麼對於畫面的整體風格（這其中postfx起了很大的作用）要求就是更豐富和更靈活。script驅動的filterchain，我們可以理解成一個材質編輯器，其每一個計算單元不是加減sample這種，而是一個個postfx的filter，比如blur， edge

http://wings11087.blog.163.com/blog/static/927152152010112913059361/文章通過實際的例子來說明幾個問題。 在牽涉合作的時候，能力和人品之外要加一個理念是否契合。兩個方案各有千秋，相差也是不多的話就沒有必要去花很多時間爭論，大家猜拳就好，產品開發唯快不破，別扯jb蛋了。 一切以實踐為準，有些大忽悠喜歡標榜自己愛爭論云云好像很敬業很牛x，這個屁用不頂，專業的就是專業的，和愛不愛爭論沒關係。 最後還是說能遇見專業的人是很不容易的，遇見這

總希望能寫出最簡潔優雅的代碼，何為簡潔優雅？我認為簡潔優雅既是會讓我們不得讚歎其對內容理解的深刻和對語言乃至系統的駕馭； 總希望在自己的程式裡面實現最炫的feature，越來越發現參照文檔和想象實現炫的feature倒是不難，可是能夠為這個feature提供足夠資源則需要深厚的功底，正如參天大樹是基於更加龐大深入的根系一樣；深入理解，堅實基礎，乃是程式員修行之道； 

 const意味著不能修改；我們的潛意識裡面要深深刻著：const是1，design的意圖2，防禦式編程，更安全而const_cast則是對於初始設計的一種破壞，是程式完美性的汙染者，hack！除此之外，可以考慮使用const帶來的optimization：1，compile time：在effect c＋＋中所介紹的，用const來代替#define，也就是先行編譯時間而且直接聲明一個POD變數為const也有可能促使compiler預先處理的時候把變數最佳化掉；2，runtime

 http://developers.solidot.org/article.pl?sid=11/01/13/0224242&amp;from=rss Randall Degges 寫道 "我已經做了很久的程式員。當我最開始編程時，我將全部心思投入到電腦中編寫代碼。雖然，My

http://hardware.mydrivers.com/2/178/178706.htm4系列入門顯卡450的比較評測。對裡面的解析度變化帶來的效能變化的資料高度興趣：對比是不同解析度下的fps。幀數對比是：1280x1024 對 1680x1050比率為：0.74 那麼幀數在各個顯卡上的差距是：  Sc2430:0.8593220---0.815550---0.83 Cod6:430:0.71220—0.755550---0.78 Farcry2:430:0.83220:0.825550:

http://www.gdcvault.com/play/1014363/Cinematic-Character-Lighting-in-STAR 是一個art的文章，但是看看也挺有意思，下下來直接看圖就好，裡面從gradient lighting，rim lighting，sky lighting等角度展示了對畫面的影響。都還不錯。 最後一點挺好的，shader應該誰來搞？美術流？程式流？他們的經驗是tech

我們需要把一切想的非常明白，非常完美才開始動身嗎？在敲代碼的時候也是在設計不是嗎？整個過程也意味著設計的提升，最後的改進；架構性的設計要非常明確，再三思考，細節性的實現可以有個概念就動手code，寫完進行最佳化和美觀；我試著考慮一個類如何輕巧的開始，明確的美化和最佳化，最後達到一個讓人滿意的程度；應該有怎樣一個原則，來把它可在骨髓裡來達到極其純熟的程度；關於public,protected,private,static這些關鍵字，意義當然都非常明白，我認為使用的過程是：1，原則：make it

再次回到設計火候的問題，相當長時間以來潛意識裡有一種疑惑，我總想在紙上儘可能詳細的設計出來，但是這種做法更加讓人疲倦而且慢。反而稍微做一下設計，然後開始寫程式，緊接著再來設計一次，然後進行重構類的修改，反而更加快速。 這個現象我們也見得很多了，敏捷方式的一個表現就是這樣，但問題是：why？ 為什麼我們不能去儘可能的詳細，然後一氣呵成的把問題搞定？因為資訊量。 面對一個規模較大或者新的問題的時候，我們在設計的根節點上可以大致做出架構---比如說這個問題需要用instance來代表每個物體，然後有一

最近幾個月在實現規模比較大的底層系統（這也是一直沒有論文閱讀更新的原因）。記錄下反思中的點點滴滴（後面會有更新）。 挑戰：大型系統的最大挑戰的根源在於其規模，以及規模帶來的複雜度，它會在幾個方面帶來挑戰：它不能一下在在腦袋裡全部浮現出來，也就是說一次只能關照一個部分（包括樹狀結構的至上而下的思考）對於體力和意志力也是一個挑戰，尤其是有deadline的情況下容易出現受迫性失誤（沒有按照完美的方法去實現）目標： “平衡”往常我們會說是“完美”才是目標，實現一個功能效率俱佳的系統，但是在實際項目中，

這個文章要解決的問題其實不算是這個generation的，但是裡面帶來一些思想或許有一些啟發，也提到不少知識，也算是複習和加深理解了。但對於實際遊戲開發來說營養甚小。我們正常做env mapping的時候是不帶occlusion資訊的，實際使用中tri

才剛剛看了The Social

兩個架構的內容出了相當的時間了，之前http://blog.csdn.net/ccanan/article/details/7859534這個文章裡面也提過。只是最近基於GK104的GTX770m，780m逐漸登場，小猶豫著是不是要等GK110的筆記本，趕緊補一下GK104和GK110的區別。 http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdfGK104，旗艦卡為GTX680，相對於

http://msdn.microsoft.com/en-us/magazine/cc301698.aspx在link時刻做的代碼最佳化。平時接觸的編譯器最佳化基本是compile time最佳化，比如inline這樣的工作。其限制就是可以做的東西就是在一個編譯單元裡，一旦調用的一個函數在另外一個編譯單元，就只有跳轉著一個選擇，至於跳轉的細節就是在link time來決定了。 link time

原帖在下文，筆記：DxFlag：像D3DUSAGE_DYNAMIC， D3DPOOL_DEFAULT， D3DPOOL_MANAGED， D3DPOOL_SYSTEMMEM這些都是給driver一些提示說我們想這樣用這些資源（靜態，動態。。。），到底這些資源會被如何管理還是driver來說了算。一些傾向是：POOL：D3DPOOL_DEFAULT：會根據usage來放置資源，基本是video mem和AGP

http://www.pcgameshardware.com/aid,776086/Civilization-5-Tech-Interview-What-DirectX-11-is-good-for/News/ 幾大應用：tessellation----主要用在terrain上，拉近開始細分，更加好的detaildirect

平常時候說的宏，一般指preprocessor，google的時候用這個比較合適，否則各種macro會悲劇。 msdn裡面有比較全：http://msdn.microsoft.com/en-us/library/wy090hkc(v=VS.80).aspx 歸檔一下以前的相關post：http://blog.csdn.net/ccanan/archive/2007/06/06/1641409.aspx變參的宏：http://blog.csdn.net/ccanan/archive/2010/11

  git越來越喜歡git，git本身理念上的提升還沒太用到，但是對於常常要offline工作的情況，裡面的push功能很好，相當於local有一個小型server，在offline情況下可以把改動存在著裡面。然後online情況下在commit到想github這種代碼託管的地方。 git extention對於不愛用命令列的同學可以用這個，各方面功能很方便。git scc provider:http://gitscc.codeplex.com/，vs

經過n次的重演之後，又來一個n+1次的重演。就是對於知識理解的不透徹，結果耗費了更多時間。在學習和閱讀的過程中還是要慢一些，理解透徹才好，否則不該快的地方快了，反而後面加倍償還。回顧之前學習和閱讀的經曆，還是潛意識裡的浮躁和想走捷徑作怪，這兩點某些時候會省一點，但是更多時候則更費，實在不可取。 然後就是對知識點理解的透徹對最終效果的展現也是巨重要，最近做的東西，演算法都比較好的實現出來了，但是效果還是比較差。需要調出一個比較好的資料才行，但是這個資料調試的效率就取決於對演算法的理解程度，理解的好