Type safe OpenGL – Converting strings into types in D
maikklein.github.io
Type safe OpenGL – Converting strings into types in D
1–10 of 10 posts
Re: Type safe OpenGL – Converting strings into types in D
#2The general idea of "importing" types is a good one and I think this is what F# achieves with type providers. I've seen this applied to database schemas and filesystems, but never OpenGL.
Re: Type safe OpenGL – Converting strings into types in D
#3This only seems useful for user-defined glsl types. The builtin glsl types would only have to be written out once as D types. The general idea of "importing" types is a good one and I think this is what F# achieves with type providers. I've seen this applied to database schemas and filesystems, but never OpenGL.
Re: Type safe OpenGL – Converting strings into types in D
#4Goal: Easy access to shaders and its respective buffers with a bare bones visualization.
Example:
Shader shader(fragment_shader, vertex_shader);
verticesVBO.set(vertices);
verticesVBO.map(shader, "inPosition", false);
shader.bind();
shader.setUniform("uViewMatrix", camera.view());
shader.setUniform("uProjMatrix", camera.proj());
shader.setUniform("uModelMatrix", modelMatrix());
facesVBO.bind();
glDrawElements(GL_TRIANGLES, facesVBO.length(), GL_UNSIGNED_INT, (void*) NULL);
I should clean it up and make it available as a library.Re: Type safe OpenGL – Converting strings into types in D
#5This only seems useful for user-defined glsl types. The builtin glsl types would only have to be written out once as D types. The general idea of "importing" types is a good one and I think this is what F# achieves with type providers. I've seen this applied to database schemas and filesystems, but never OpenGL.
Maybe its because OpenTK has type safe bindings(OpenGL, OpenCL and OpenAL) for F# and C#.. http://www.opentk.com/
https://github.com/opentk/opentk/tree/develop/Source/Bind/Sp...
The */override.xml files contain directives to convert the official Khronos XML specifications into type-safe versions. All you need is a code generator for your language of choice.
If anyone is interested in trying this, I encourage you to contact the developers on github (there used to be C++ and Java code generators that have since been removed.)
Re: Type safe OpenGL – Converting strings into types in D
#6I'm currently doing something similar in C++ based on a project I worked on a couple of years ago. It is a wrapper around OpenGL for people like me who are tired of figuring out the specifics of the OpenGL calls every time they write something. Goal: Easy access to shaders and its respective buffers with a bare bones visualization. Example: Shader shader(fragment_shader, vertex_shader); verticesVBO.set(vertices); ver…
I still find it kind of uncomfortable that I'm copy-pasting variable names as strings between (the middle of!) the shader code string and the use sites (e.g. `setUniform` calls) -- I'd like it if I got some sort of quick compile time sanity check that those references match up. Had you considered going that far, and if so, what were your thoughts?
Re: Type safe OpenGL – Converting strings into types in D
#7I'm currently doing something similar in C++ based on a project I worked on a couple of years ago. It is a wrapper around OpenGL for people like me who are tired of figuring out the specifics of the OpenGL calls every time they write something. Goal: Easy access to shaders and its respective buffers with a bare bones visualization. Example: Shader shader(fragment_shader, vertex_shader); verticesVBO.set(vertices); ver…
I've been fooling around with Go bindings to GL and also want to do something similar. I still find it kind of uncomfortable that I'm copy-pasting variable names as strings between (the middle of!) the shader code string and the use sites (e.g. `setUniform` calls) -- I'd like it if I got some sort of quick compile time sanity check that those references match up. Had you considered going that far, and if so, what wer…
My advice would be: don't do this.
If you can afford to support OpenGL 3.1+, use uniform buffer objects with the std140 layout instead. That way, you can create a strongly-typed struct in your code and access it normally on the CPU side. Uploading to the shader then is done with a single *BufferData call.
See [1] for more information.
Re: Type safe OpenGL – Converting strings into types in D
#8I'm currently doing something similar in C++ based on a project I worked on a couple of years ago. It is a wrapper around OpenGL for people like me who are tired of figuring out the specifics of the OpenGL calls every time they write something. Goal: Easy access to shaders and its respective buffers with a bare bones visualization. Example: Shader shader(fragment_shader, vertex_shader); verticesVBO.set(vertices); ver…
Re: Type safe OpenGL – Converting strings into types in D
#9Earlier quoted context omitted.
Maybe its because OpenTK has type safe bindings(OpenGL, OpenCL and OpenAL) for F# and C#.. http://www.opentk.com/
It took an awesome amount of work to get that level of type-safety. Now that this is in place, other languages could use that infrastructure to provide type-safe bindings: https://github.com/opentk/opentk/tree/develop/Source/Bind/Sp... The */override.xml files contain directives to convert the official Khronos XML specifications into type-safe versions. All you need is a code generator for your language of choice. If…
What was the reason for removal? Difficulty of maintenance? Out of scope for a C# project?
Re: Type safe OpenGL – Converting strings into types in D
#10Earlier quoted context omitted.
It took an awesome amount of work to get that level of type-safety. Now that this is in place, other languages could use that infrastructure to provide type-safe bindings: https://github.com/opentk/opentk/tree/develop/Source/Bind/Sp... The */override.xml files contain directives to convert the official Khronos XML specifications into type-safe versions. All you need is a code generator for your language of choice. If…
>there used to be C++ and Java code generators that have since been removed. What was the reason for removal? Difficulty of maintenance? Out of scope for a C# project?
It's also a bit tricky because some .Net assumptions are hardcoded (i.e. overload resolution, generics, pointers+references), which makes it harder to generate idiomatic code for other languages. Nothing that cannot be fixed with a bit of effort if someone interested shows up, but until then it's better to generate excellent bindings for one runtime than mediocre bindings for multiple (and pretty much every runtime comes with a mediocre OpenGL binding.)