[GEM-dev] gemframebuffer flood

Guido Tamino guido.tamino at gmail.com
Wed Oct 26 12:08:04 CEST 2011


Hi Cyrille,

> imagine a 10 pixels size frambuffer. in rectangle mode, coordinate  
> goes from 0 to 1. so 1st pixel coordinate goes from 0 to 0.1, 2nd  
> pixel goes from 0.1 to 0.2 etc.
> so 1st pixel center is at 0.05 and 2nd pixel center is at 0.15
> when rendering in gl_linear, you interpolate between pixels. so  
> reading texture at position 0.05 gives exactly the color of the 1st  
> pixel.
> but reading at 0.1 gives a mix between 1st and 2nd pixel.
> now, if you have to read at position 0.01, then, you also have to  
> interpolate. between 1st pixel at position 0.05, and previous pixel.  
> this previous pixel can be the same as the 1st one in "repeat 0"  
> mode, or the same as the last pixel of the texture (position 0.95)  
> in "repeat 1" mode.

this makes perfect sense, wonderful.

I think we are getting close to the osx issue. As you said before, the  
0 and -0.5 position in a normalized texture (no rect) with no repeat  
should have the same color of the 1 position (the first pixel), but it  
doesn't. This is clearly visible if i change the texture coordinate,  
see the image. I guess this is causing the problem in the same way the  
pixel size not fitting the rendering size was causing the repeat  
artifact.

http://img256.imageshack.us/img256/9208/texturei.png

Thanks for your solutions but none of them is completely solving the  
problem. The framebuffer size can't be fixed as it is changing wildly  
while adjusting the blur amount, gl_nearest (quality 0) will bring  
weird artifacts and the glsl thing is pretty clever but feels like a  
workaround to me.

Best,
Guido



More information about the GEM-dev mailing list