Closed Kagami closed 9 years ago
:+1: I'll give it a try (at some point).
I've pushed change to a test branch if you'd like to check. Really don't understand what's going on. Online resources say everything should be ok: https://stackoverflow.com/questions/16950490/process-single-channel-image-by-glsl-texture https://stackoverflow.com/questions/16130880/passing-an-8-bit-alpha-only-texture-to-glsl
I verified that it's broken on my machine too. Apitrace doesn't show anything extra-ordinary - the GL call are correct. I can only assume something wrong with the data.
One thing I find abnormal is that the data you pass in is bigger than the texture size:
We could certainly assert on that in gfx-rs or return an error. But you must be doing something wrong when constructing the image in the first place. It's allocated here:
let mut image = Vec::with_capacity((image_width * image_height) as usize);
And then it's filled with multiple .extend(...)
calls, but nowhere does it ensure that the resulting size is what you expect. Perhaps, add an assertion per line to match the expected size?
Nevermind... I added asserts and logging, and the numbers look correct, and nothing fires up.
Ok, I figured this out. See https://github.com/gfx-rs/gfx-rs/issues/733
Since freetype provides grayscaled data, it's a waste of space and probably efficiency to store additional meanignless zeroes. I tried to use
gfx::tex::R8
andt_Font_Color.r
instead of.a
in shader but sometimes was getting artifacts because of that.Probably there is some error in shader and/or library code or you can't just blend R8 texture with vec4 color provided by user with default texture sampler. Needs additional investigation.
cc @kvark