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.


4 Responses to “Fun fact: WebGL shaders are way different from GLSL shaders”

  1. snooze82 says:

    what about varyings?
    varyings are shared between vertex and fragment shaders.

  2. Will Edwards says:

    The “show us the code” aspect is really only to discourage cheating. Its not you giving people permission to *use* the code.

    You can retain full copyright personally, or assign it CC-BY-NC-SA or whtaver else.

  3. bvanschooten says:

    Not sure what exactly you are trying to do with your shaders, but I can tell you that WebGL is virtually identical to OpenGL ES 2.0 (not 1.0). You can pass data from vertex shader to fragment shader just fine, using a varying variable (as mentioned by snooze82). It works like this:

    You define a varying with a particular name in both vertex and fragment shaders. The vertex shader assigns a value to the varying. The primitive assembly/rasterizer then translates the vertices into polygons and pixels, and interpolates the varyings appropriately for each pixel (fragment). For example, if your vertex shader defines a varying vec4 colour that is black for one vertex and white for the next, and you assemble the output into triangles (as in drawArrays(TRIANGLE_STRIP,…), then the endpoints of your triangles will be black or white, and the rasterizer will assign greyshades along the edges and inside each triangle to smoothly interpolate the colour between the endpoints.

  4. CubeGod says:

    @snooze82, yes I eventually managed to dig that info up from apple’s iOS documentation of all places (about the last place I’d ever think of looking)

    @Will Edwards, I figured as much but thanks for clarifying.

    @bvanschooten, indeed I’ve gotten quite a few test shaders to compile to do all sorts of things http://i.imgur.com/aVVKMJL.png

    I really don’t like whatever GLSL version ES 2.0 is using, it’s weird; but on the other hand it works so there’s that.
    Now with all my shader code, texture code, sprite rendering code, etc working I’ve almost completed my task of writing a ‘lil game engine for the compo; thanks a lot to all of you for verifying my assumptions, it does rather help to know that my shaders work correctly instead of being bastardizations that work entirely due to quirks in OpenGL (i.e relying on undefined behavior)

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]