Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm currently building a fragment shader which is using several textures to render the final pixel color.

The textures are not really textures, they are in fact "input data" to be used in the formula to generate the final color.

The problem I've got is that the texture are getting bi-linear-filtered, and therefore the input data as well. This results in many unwanted side-effects, especially when final rendered texture is "zoomed" compared to original resolution.

Removing the side effect is a complex task, and only result in "average" rendering. I was thinking : well, all my problems seems to come from the "default" bi-linear filtering on these input data. I can't move to GL_NEAREST either, since it would create "blocky" rendering. So i guess the better way to proceed is to be fully in charge of the interpolation.

For this to work, i would need the input data at their "natural" resolution (so that means 4 samples), and a relative position between the sampled points. Is that possible, and if yes, how ?

[EDIT] Since i started this question, i found this internet entry, which seems to (mostly) answer my needs.

One aspect of the solution worry me though : the dimensions of the texture must be provided in an argument. It seems there is no way to "find this information transparently". Adding an argument into the rendering pipeline is unwelcomed though, since it's not under my responsibility, and translates into adding complexity for others.

share|improve this question
up vote 1 down vote accepted

the dimensions of the texture must be provided in an argument. It seems there is no way to "find this information transparently".

What, are you stuck in GL 2.1 land? We've had textureSize in GLSL for years now.

share|improve this answer
The link you provide also give information on texelFetch(), which is exactly what i was looking for. Many Thanks. My very last small issue to solve is how to deal with "border of textures", which appear black. I guess it must be a matter of wrapping detection and policy. – Cyan Nov 17 '12 at 1:34
@Cyan: Note that you may also be interested in textureGather. It's a 4.x feature, but available on a limited set of AMD's 3.x cards (HD 4xxx's). – Nicol Bolas Nov 17 '12 at 1:56
Thanks, it's even more straightforward : a single function call which does all the job. Nice. Unfortunately, I fear i cannot program for GLv4+ only at this stage, but that's nonetheless very useful to know. – Cyan Nov 17 '12 at 2:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.