现在的位置: 首页 > 综合 > 正文

图形层——纹理功能

2013年01月01日 ⁄ 综合 ⁄ 共 815字 ⁄ 字号 评论关闭

    好久没写了,昨天天气不错,今天周末,写2句。

    啊,上次的场景编辑器里面的物件放置弄完了。要开始改造现在的引擎内容,按我们理所当然的想法进行了图形层的划分。

我就开始做纹理功能部分,真是好多呀,需要使用的纹理类型不说,而且像素格式也是好多种,转换函数都好多。

    参考其他资料和按我理所当然的想法,由于是封装DX的纹理接口,我就另外有一个图像类存2维像素图,一个纹理接口类和DX相关,给图形层其他功能的使用。另外有一个相当于Photoshop滤镜的程序纹理构造类,使用算法生成一些特殊纹理(不过现在算法没写几个,哈哈~后面加点噪声和云彩之类的)。纹理的mipmap、缩放、像素格式转换这些函数都放在独立一个命名空间中(像素格式转换常用的做了,嘿嘿,太多了先用到)。图像从硬盘的加载和存储也单独加载和存储类,实现和DX无关,使用文件流和具体图像格式的库完成(暂时支持的类型还不是很多)。纹理会根据硬件的支持性,自己将不支持的格式转换成支持的类型。

    还有些问题存在,还不支持的环境纹理、体积纹理。在Cpu对纹理进行采样访问纹理某一具体点的像素值时,纹理采用实际纹理坐标还是[0,1]的规范坐标?纹理所返回像素值时具体各个格式的值(R8G8B8A8,R5G6B5……这会造成编写代码时不确定性),还是返回规范化的每个通道都是[0,1]的值(像着色器中的值一样)?DX渲染到纹理的处理,我们把DX的渲染表面和纹理接口整合到一起了,所以从图形层控制类返回渲染目标和设定渲染目标时,有不被定义因素和很大不方便。那个程序纹理构造类的组织感觉不够好,本想能供使用着能提供自定义的构造算法,但因为图形层要做成DLL,所以默认的构造类的创建绕了个弯。

    嘿嘿,这些东西后面慢慢完善吧,先有个可以使用的版本用着,可能还有些设计方面需要改动。我想可能要持续不断的完善和优化这样对细节地方和大的宏观内容都有个好的把握。

    欢迎大家指责、批评。

抱歉!评论已关闭.