diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2022-12-06 14:26:57 -0800 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2022-12-06 14:26:57 -0800 |
commit | 4251e47f991bfd032a75159b0b8c8e2a4b7346b4 (patch) | |
tree | 9b8d4ccc3eb045cdd8cd14c31a0c7db1c1802887 /assets/five.ans | |
parent | ddc29bf8cfbfb2a455b627805174697863046bfd (diff) |
plasma-node,tex: GLSL 1 and 1.2 versions of shaders
Emscripten support is strictly GLES2 which is why the shaders
were migrated to GLSL 1. I was hoping the already supported
desktop operating systems would be able to handle the GLSL 1
shaders and GLES2-constrained API usage on a GL 2.1 context, but
MacOS seems to be angry about this, Tara reported testing
rev4-rc{9,10}:
Fatal error: Error compiling vertex shader: "ERROR: 0:1: '' :
version '100' is not supported
Which is further than rc8 got, that couldn't even create a
window. And since this seems to be at least reaching shader
compilation, which is pretty deep into sars as far as exercising
GL functionality, I'm just resorting to gross granular #ifdef
__EMSCRIPTEN__ fuckery in the shaders to provide GLSL 1.2 shaders
on non-emscripten builds (including MacOS), and GLSL 1 shaders on
just emscripten.
Fortunately in sars there just isn't much shader code, so it's
not especially painful.
But future titles building upon this codebase and these
assumptions may become quite painful if using this approach to
support emscripten and desktop GL. Or if sars evolves to make
more sophisticated use of shaders, this could introduce
substantial development and maintenance overhead.
TL;DR: I hate this commit, but it seems like the shortest path
right now to make everything happy again in an emscripten
supported world.
Diffstat (limited to 'assets/five.ans')
0 files changed, 0 insertions, 0 deletions