Don't know what API/version you're using, but OpenGL's Image Load Store is handy for this kind of thing. So long as you are operating on pixels independent of their neighbours no need for for a copy and bypass sampler nonsense, can bypass all the render-to-texture nonsense too if you use compute shaders. D3D has an equivalent too but can't remember the details that'd be RWTexture*.
Using OpenGL, and that's handy! I decided not to do the darker color shader because even with that it's more hassle than it's worth it to me xP But I'll probably find a use for that in the future when I'm more comfortable with shaders in general. Sticking to really basic stuff for now.
More OpenGL shader ???ing, in case anyone's in the mood to read about a noob struggling with the basics!
I'm playing around with applying color maps and I've just broken my brain. As far as I'm aware, OpenGL texture coordinates have their origin at the
bottom left, and that's how it's worked so far. I am using this colormap for testing:
It has its origin at the
top left, and the y coordinate corresponds to green (high y = high green). So, this should mean that in my shader where the origin is at the bottom, high green should mean low y, achieved with y = 1.0 - green:
vec2(pixel.b/16 + floor(pixel.r*16)/16, 1.0-pixel.g)But that makes a mess, and it seems I should be directly using green as my y coordinate:
vec2(pixel.b/16 + floor(pixel.r*16)/16, pixel.g)This gives me the desired results (hardly any visual change to the image). Am I misunderstanding something? Having a brainfart? When the green component is 0, I'd expect that second coordinate to mean the bottom of the color map, so why is it giving me the top?
Edit: Maybe it's something to do with SFML and how it handles textures? Now that I think of it, I think my previous attempts also had y = 0 at the top, it just didn't matter as much on those so I didn't notice.
