The flickering is actually a different issue -- you've got a single-buffered GL context, so GL is drawing directly to the screen. The reason you see it more with GL_LINEAR because it's slower to render. To fix this, you need to request a double-buffered context from whatever you're using (GLX, SDL, Win32, etc.). It's easy to fix; you just add the right flag in the right place.

believe it or not, I am using double buffering. I think... I am fairly sure it is double buffered since I am making a call to SDL_GL_SwapBuffers after every draw.

Actually I said the problem was LESS with GL_LINEAR not worse. I know what you were saying about the double buffering but I actually think it is because of my original problem that the OpenGL texture coordinates are either innacurate or I'm am using them wrongly.

If anyone is interested I could even post a screenshot to show what is happening...

My problem can be summarised like this:

If I have a 256 by 256 texture. And I'm using GL_NEAREST. And I do the following for given doubles x and y:

glTexCoord2d(0, 0);           glVertex2d(x, y);glTexCoord2d(0, 0.0625);      glVertex2d(x, y+16);glTexCoord2d(0.0625, 0.0625); glVertex2d(x + 16, y + 16);glTexCoord2d(0.0625, 0);      glVertex2d(x + 16, y);

I should get ONLY the texels in the upper 16 by 16 block of my texture drawn to the screen. Am I correct in this assumption?

Because OpenGL is not doing this. Instead I am getting neighbouring texels in there - ie texels in columns 17 of my texture.

Hope that wasn't too terse, and made my point clearer.

No, don't think that sounds right. You should be dividing by 256. Texel 0 is at 0/256. And texel 256 is at 255/256. That would be the upper left corner of the texels. So a span of 1 texel is [0..1/256] and a span of 16 would be [0..16/256].

Probably float rounding errors since you're accessing the very edges of the texels. Try adjusting your texcoords to:

glTexCoord2d(0.001, 0.001);           glVertex2d(x, y);glTexCoord2d(0.001, 0.0624);      glVertex2d(x, y+16);glTexCoord2d(0.0624, 0.0624); glVertex2d(x + 16, y + 16);glTexCoord2d(0.0624, 0.001);      glVertex2d(x + 16, y);

and see if it makes any difference.

Enigma

Yeah, thats not a bad idea. I already tried that too, but a similar problem kept occuring. It is as though: when glOrtho is set at a particular position, the tiles get their textures shifted by 1 texel. Wierd. I have decided I need to put up a couple of screenshots to make it clear...

http://users.bigpond.net.au/rz/right.tiff
http://users.bigpond.net.au/rz/left.tiff

Sorry, they are tiffs, I know, but I think most people can view tiffs in their browsers. The two pictures are scrolled to *almost* the same position. right.tiff is a tiny minute bit to the right of left.tiff. And notice what happens!

nb: if people want I can convert them to jpegs but for some reason the tiffs are really well compressed...

well, I have solved the problem. Hooray. It turns out that there were two problems I was having...

1) I used integer coordinates for glOrtho (I think someone might have suggested this above)
2) (1) solved half the problem, but I had terrible flicker. Turns out this was not caused by single buffering or anything - it seems to be something to do with an lcd display. On my iMac with a CRT display it looks perfect now.

I still don't know why it would dlicker like that on an lcd, but at least I know the problem isn't actually in my code...