Evening all, my brain got stuck on an unnecessary API design question the other day in working through Handmade Hero Day 241 and 241 learning the benefits to this setup.
Casey uses the three tier architecture between Win32, Game Code and OpenGL specifics. If you were working this architecture in a multi-use engine, and were allowing the developer on the game code side to write their own shader without exposing the OpenGL tier, would you expose a CreateShader(u32 Index, char* VCode, char* GCode, char* PCode, etc...) through the platform/render API globals attached to the GameMemory struct, add it as a new RenderCommand type during initialization, or a totally different approach?
Would the game code side hold the reference to these shaders, or would the "engine" side manage an array of shaders that the game code side could grab by an index or char name?
Thanks in advance for the thoughts on this.
-Mebourne
Casey uses the three tier architecture between Win32, Game Code and OpenGL specifics. If you were working this architecture in a multi-use engine, and were allowing the developer on the game code side to write their own shader without exposing the OpenGL tier, would you expose a CreateShader(u32 Index, char* VCode, char* GCode, char* PCode, etc...) through the platform/render API globals attached to the GameMemory struct, add it as a new RenderCommand type during initialization, or a totally different approach?
Would the game code side hold the reference to these shaders, or would the "engine" side manage an array of shaders that the game code side could grab by an index or char name?
Thanks in advance for the thoughts on this.
-Mebourne
Edited by Scott Hunt
on
shader code is very tightly linked to the api underneath.
That means that if you ever change APIs (or even upgrade to the next version in some cases) you will need to translate the shader code. Either manually or automatically.
Related to that is how you tie the shader inputs and output to the user-side IDs, so the renderer will will need some meta data along with the shader code to tie it all together.
Also consider vulkan, there the graphicspipeline object (which contains vertex attribute format, uniform bindings, blending, ...) is immutable once created and its creation is expensive.
That means that if you ever change APIs (or even upgrade to the next version in some cases) you will need to translate the shader code. Either manually or automatically.
Related to that is how you tie the shader inputs and output to the user-side IDs, so the renderer will will need some meta data along with the shader code to tie it all together.
Also consider vulkan, there the graphicspipeline object (which contains vertex attribute format, uniform bindings, blending, ...) is immutable once created and its creation is expensive.