修改于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!