I have different games using different libs.
However almost all of them have the same problem: Zooming causes bleeding.
http://img440.imageshack.us/img440/2446/bleeding3.jpg
Here an isometric example
http://img96.imageshack.us/img96/7710/bleeding2.jpg
So I would appreciate it if you OpenGL experts would talk about: How, when and why it happens; and also of course how to avoid it.
I not sure what visual defect you’re referring to. As a guess: RGB colors even if alpha is 0 DO count, due to sampling.
This occurs because the filtering is set to GL_LINEAR. Bilinear filtering will select the nearest four pixels and blend them using a weighted average. As Roquen said, the RGB is blended even if the adjacent pixels have an alpha of zero.
For example, this 32x32 grass tile is located at (1, 1) on the sheet.
We see bleeding when we scale up:
This is because when GL goes to sample the edge pixels of our grass tile, it blends the grass with adjacent pixels (magenta).
The solution is to use GL_NEAREST for our sprite sheet, which only picks the “nearest” colour and doesn’t blend adjacent pixels.
If the images don’t need to be tiled, we could instead simply pad our sprite sheets with some transparent white pixels.
What if you need GL_LINEAR, and your sprites need to be tiled? Even if you pad the sprites, you will end up with bleeding (whatever is behind our tiles will bleed through, as it appears in your first screen shot). One hack/solution to this is to pad our sprites with pixels taken from opposing edges. The top line of pixels taken from the bottom, the left line of pixels taken from the right, etc:
The result when scaled:
This problem may also manifest itself if you’re loading non-power-of-two textures with Slick/SlickUtil. In that case, Slick pads the extra dimensions (to make it power of two) with transparent black pixels. Therefore bleeding on the bottom/right edges may occur using GL_LINEAR, even if the scale is unchanged.
tl;dr - don’t use GL_LINEAR
Bleeding may also occur if you are using non-power-of-two texture regions (i.e. sprites), due to floating point inaccuracies. Ideally you should stick to power-of-two where possible.
If you’re okay with limiting yourself to OpenGL 3+ cards you could just use a 2D texture array to hold the tiles. It’s basically a 3D texture, but it won’t interpolate between layers, meaning that you can create a 32x32xNUM_TILES texture array, and it magically works with filtering, mipmaps, etc since you can just enable GL_CLAMP_TO_EDGE.
Of course not. >_>
Many older cards support texture arrays through extension (GL_EXT_texture_array). My OpenGL 2.1 card supports it.
Cero is rage-appreciating here 
[Note: this is an unrelevant post, which is not necessary. This is also not edited 
]
Hi we had some problems with sprites, where the borders where looking ugly so we made a tool that bleeds the colors of the opaque pixels into the transparent ones, the pixels that are not 100% transparent are not changed, but the transparent pixels get the color of the neighouring pixels. This fixes the interpolation error that usually happens in those pixels.
The tool does this:
the left image is the original one rendered over a red background, the middle one is the result with alpha disabled, and the right one is the result image rendered over a red background with alpha enabled.
The projects is available here: https://github.com/gemserk/imageprocessing and there is a runnable jar in the downloads section.
If you have any question feel free to ask.
I saw someone appreciating posts in this thread that wasn’t me - even though it was my question and I even say I would appreciate it. SO I figured, I gotta use that feature more often ;D
[quote]https://github.com/gemserk/imageprocessing
[/quote]
Looks like its rather for sprites than tiles
For tiles its more complicated…
Padding seems to work, however, I have of course build an entire game around these existing tilesets.
So we going to try to use texture arrays…
Here is merge of the the gemserk’s source code with the available source code of the TexturePacker: http://jfix.by/wp-content/uploads/2013/02/TexturePackerGemserk.zip
(+ explanatory blog-post http://jfix.by/2013/02/23/opengl-filters/)