修改於2015年9月6日:html
去年寫這篇解決方案的時候其實對着色器編程還只知其一;不知其二,摸索了一個治標不治本的方法解決問題,結果被一個CSDN的博主原封不動抄了去,還打上個原創的標籤= =,簡直無語。。。編程
最近從新開始深刻學習DX,對這個問題摸索到了更合理的解決辦法,在此從新記錄一下。函數
2014年4月的解決方案:學習
這個問題出現的緣由是將.fx文件(着色器文件)導入本身新建的工程之後,VS2013會默認使用HLSL編譯器對其進行編譯,而.fx文件中並未定義main函數,因此會致使編譯出錯。動畫
解決方法是:spa
右鍵.fx文件,「屬性->配置屬性->常規->項類型」,將「HLSL編譯器」改成「不參與生成」htm
2015年9月的解決方案:blog
按照正常的DirectX程序執行流程來講,着色器文件是在程序啓動的時候才被編譯與執行,但如此一來,當着色器程序出現語法錯誤時Debug便變成了一個噩夢。get
所以,VS2013爲你們提供了一我的性化的功能,那即是在程序編譯時加入了對着色器代碼的語法檢查。去年寫這篇博文時提供的解決方法即是讓編譯器跳過了對着色器的語法檢查,從而讓程序可以正常運行。編譯器
那麼問題來了:
爲何在着色器代碼在可以正常執行的狀況下編譯器還會對着色器文件報「entrypoint not found」的錯誤呢?
這個問題的答案以下:
不一樣於C/C++程序,着色器程序的入口函數名是能夠由用戶本身定義的,而VS2013將着色器程序的默認入口函數名與C/C++同樣設爲了「main」,而DirectX Tutorial中的着色器代碼並不不是以「main」做爲程序入口點,因此纔會報出上述的錯誤。
新的解決方法以下:
1. 右鍵.fx文件,「屬性->配置屬性->常規->項類型」,將它的值改成「HLSL編譯器」
2. 點擊右下角的「應用」按鈕,會發現左邊的「配置屬性」菜單中多了一個「HLSL編譯器」的菜單,點開後選擇「常規」
3. 「入口點名稱」改成着色器文件中對應的函數名
4. 「着色器類型」改成對應的着色器類型(通常爲頂點 or 像素着色器)
5. 「着色器模型」改成對應的着色器版本
使用這個方法就能夠在解決問題的同時使用VS2013對着色器代碼進行語法檢查了,OVER!