Skip to content

GLES: Avoid global set of enums, and make enums for each function's valid inputs #5

@rdunnington

Description

@rdunnington

OpenGL/ES defines a large number of values that have virtually no type safety - you can often pass completely unrelated values such as:

  • GL_BUFFER_USAGE
  • GL_DEPTH_FUNC
  • GL_VIEWPORT
    to parameters that take an unsigned integer, and get no type checking to help you fail faster. A straightforward example would be:
const ShaderType = enum(GLenum) {
	Vertex = 0x8B31,
	Fragment = 0x8B30,
	Compute = 0x91B9,
};
pub fn glCreateShader(shader_type: ShaderType) GLuint {}

Note that in the native API, you could pass any integer, where with this system you could only pass valid parameters. This gets a lot of value when dealing with more complicated functions:

// Raw openGL binding:
extern fn glFramebufferTexture2D(target: GLenum, attachment: GLenum, textarget: GLenum, texture: GLuint, level: GLint) void;
// Zig binding:
const FramebufferTarget = enum (GLenum) { ... };
const FramebufferAttachment = enum (GLenum) { ... };
const TextureTarget = enum (GLenum) { ... };
pub fn framebufferTexture2D(target: FramebufferTarget, attachment: FramebufferAttachment, textarget: TextureTarget, texture: Texture, level: GLint) void {}

For variable-sized values such as fn glActiveTexture(texture: GLenum) void, which takes GL_TEXTUREi to GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS - 1 values, these can still be generated for the user at comptime into a bounded typesafe enum.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions