我不确定这是否是正确的术语,但我相信我正在尝试做的是在 OpenGL ES 2.0 上为 GLSL 着色器编写一个“管道”。这个想法是,如果你愿意,这将是一个方便的组件,它将进入我引擎的图形管道。我的目标平台是安卓。我想对我背后的设计方法提出一些批评。简而言之,我似乎面临着要么创建一个动态处理管道,我只能简单地指定一些设置并为其添加值,要么自动化程度最低,但仍然保持相对较低的水平编写了多少代码,以及代码在做什么。
细节
到目前为止,我的设计方法如下:
- 着色器文件存储在 assets 文件夹中
- Java 充当前端,获取所有着色器文件,并将每个文件存储在一个 Shader 对象中,该对象包含有关着色器类型和原始着色器源的信息。
- Java 然后将这些自定义着色器对象(即,还不是 OpenGL 着色器对象)数组中的着色器数据发送到 C++,然后由 JNI 解析。
- 之后,JNI 将通过 Java 获得的着色器源发送到 ShaderHandler 类单例,该类单例保存
std::vector< std::vector< GLuint > >
每种着色器的多维(一个用于顶点,一个用于片段,一个用于纹理等)。- ShaderHandler 类将着色器对象编译和链接到可编程接口中,一旦完成,它通过将其功能扩展到充当 ShaderVariable 处理程序的组件类,通过动态分配值来引导大部分繁重的工作。例如,一次可以简单地指定一个值/向量/矩阵/whatever 和要修改的索引数量,并将其传递给 ShaderVariable 处理程序。一旦 SVH 获得,它就会将其存储在 a 中
std::map
,使用变量的名称作为其标识符。
- ShaderHandler 类将着色器对象编译和链接到可编程接口中,一旦完成,它通过将其功能扩展到充当 ShaderVariable 处理程序的组件类,通过动态分配值来引导大部分繁重的工作。例如,一次可以简单地指定一个值/向量/矩阵/whatever 和要修改的索引数量,并将其传递给 ShaderVariable 处理程序。一旦 SVH 获得,它就会将其存储在 a 中
- 当提示时,这些 SVH 对象(存储在位于 ShaderHandler 类中的向量中)本质上动态绑定其 std::maps 中存在的任何值的属性和制服。
分配的一些内存是通过指针完成的,但不可否认,其中大部分是由堆栈组成的。我想知道我是否应该为此考虑更多的动态内存分配,因为在Android手机上,我认为堆栈溢出可能非常非常容易通过这样的方法实现,对于具有良好图形等的雄心勃勃的游戏。
想法?