Fun fact: WebGL shaders are way different from GLSL shaders
I’m not entirely certain how I can pull data from the vertex shader into the fragment shader, after writing a quick test shader and butchering it until it worked I didn’t manage to pull vertex colors.
But that’s fine, that’s actually fine. This works too; I just have to be a bit more peculiar about it (I WAS going to pull vertex colors as a lazy way to color sprites because that would save a huge time), if I can’t get my engine to support that I’ll just work around it.
(webgl shaders are essentially GL ES 1.0 shaders and they don’t support in/out or inout)
Regardless, still in.
On the bright side, there’s no API I could possibly know better than that of my engine, I wrote it after all (in two days nonetheless!); it’s deceptively simple with only five four graphical functions.
Sprites.
Tiles.
Textures (global resources set up for use by sprites, tiles and shaders).
Shaders.
add simple bounding box intersection physics and a very crude SDL2 audio wrapper and you have yourself a deceptively simple engine with a potentially huge power:simplicity ration (because shaders, all the magic happens in the shader code… and it’s not that interesting, it’s really rather close to the reference implementation because the OpenGL documentation is very robust).
Also licensing. I have to figure out if the ludum dare supports the CC-BY-NC-SA license, because when I invariably release my source code I will release it as such, it’s for people to learn from, not earn from. 馃槈
Anywho, back to coding, if someone has a clue as to how one would solve my shader predicament that’d be lovely but in worst case I’ll just not use vertex colors, that’s fine too.
I need to finalize my interfaces, do a bit more unit testing and polish up my audio implementation.
varyings are shared between vertex and fragment shaders.