Replies: 4 comments 2 replies
|
This is not desirable feature. There are supported platforms where this can't be done. |
0 replies
|
Ok, I understand that - but what about changing the shaderc so that people who need to use it at runtime can do it without modifying the code? |
2 replies
|
Hey man, I've forked bgfx and integrated brtshaderc so it now can compile shaders at runtime in a limited number of platforms, as @bkaradzic said. |
0 replies
|
This would nice to have for compile-time asset processors, regardless of platform support. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hello everyone,
I'm trying to use shaderc as a library, to be able to compile shaders at runtime(from/to memory), but I had a few issues with duplicate symbols with bgfx.
If I change a few files in tools/shaderc folder to reference the stuff from the main bgfx(mostly removing implementations of duplicate functions), I can get my app to compile. This will probably break making shaderc executable unless it's linked with bgfx lib.
I was wondering if it makes sense to change the shaderc a bit more so that it's easier to use in this scenario?
I'm up for doing it and creating a pull request, but maybe it's better if we discuss it first a bit.
Is it a good approach to change shaderc source to use functions from bgfx and link the shaderc executable with the main bgfx library?
Maybe there is a better solution, perhaps renaming the bgfx namespace in shaderc?
Thanks for your input!
nesa
All reactions