Hi fellow gamedev! nice to see y'all.

So I've been thinking of how to texture map a game level. I've noticed that quite a lot of game in the good ol' days use the Texture Atlas technique or some sort of variations of that. One game that I've been exploring recently was Spyro the Dragon. Spyro the dragon use the Texture Atlas technique as proven by the following youtube video

Clicky

What stroke me was I saw no bleeding at all and the world looks smooth, proving that filtering is enabled. I dunno, but perhaps it was trilinear filtering. Now I wonder how it was possible. Perhaps they carefully calculate the texture coordinate but as far as I remember, the filtering should bleed the neighboring texel over. But as you can see at this video, you can see that no bleeding is visible.

How was that possible? I mean it should only work by limiting the camera angle (too low and you'll get bleeding). But as you can see in the game, the camera angle was kinda low enough that the trilinear filtering should kick in. But it didn't. How did they do it?

That video has too low quality and not enough closeups to really determine.. could very well be bleeding if arbitrary "sub-textures" were tiled next to each other.

Also, I'm not sure exactly what you want to accomplish. There are two different possible requirements here.

1. No bleeding - only requiring that no part of a neighboring texture bleeds into the current texture

2. Smooth transition - zooming in on the edge between two arbitrary tiles has a bilinearly filtered edge if magnified so the texels occupy many pixels on screen.

If you have for example 3 different square textures, one red, one green, and one blue, and each of these 3 must be able to tile into the others in every direction, and they must be properly bilinearly filtered, so that zooming in on the edge between red and green yields a smooth red -> yellow ->green transition, and same for each other texture, then it can pose quite a problem, unless you write a shader that does custom bilinear or something like that..

If you just need them to not bleed, like clamp to edge but in a texture-atlas, simply add borders to the textures.

That video has too low quality and not enough closeups to really determine.. could very well be bleeding if arbitrary "sub-textures" were tiled next to each other.

Also, I'm not sure exactly what you want to accomplish. There are two different possible requirements here.

1. No bleeding - only requiring that no part of a neighboring texture bleeds into the current texture

2. Smooth transition - zooming in on the edge between two arbitrary tiles has a bilinearly filtered edge if magnified so the texels occupy many pixels on screen.

If you have for example 3 different square textures, one red, one green, and one blue, and each of these 3 must be able to tile into the others in every direction, and they must be properly bilinearly filtered, so that zooming in on the edge between red and green yields a smooth red -> yellow ->green transition, and same for each other texture, then it can pose quite a problem, unless you write a shader that does custom bilinear or something like that..

If you just need them to not bleed, like clamp to edge but in a texture-atlas, simply add borders to the textures.

+1. Yesterday I did a deeper research on this matter. I had to either put enough pixel border, or repeat the texture 2x inside the atlas and sample the middle part (basically border that is half the texture's size). My only goal was to eliminate bleeding. And I think that's the only way.

The PlayStation 1 didn't have texture filtering so for something running natively on it this wouldn't have been an issue.

I don't think that video is being 100% honest to the source material; in fact I suspect that for rendering it's unpacked the atlassed textures and drawn them as separate textures. Doing so would also allow mipmapping to be used, which is another problem with atlasses.

Nowadays, and provided all textures were the same size, you could use a texture array instead. No bleeding and mipmapping will work too.

Sadly, I was targetting my android phone which only support gles2.0 at max. No texture array for me :'(
Anyway perhaps the reason why there was no visible bleeding was because the size of the furthest mipmap is roughly equal to the base size of the texture. So there was barely minification, mostly magnification filtering. Do you think it was a feasible explanation?

Nowadays, and provided all textures were the same size, you could use a texture array instead. No bleeding and mipmapping will work too.

Even without texture arrays, you can generate mipmaps and write a shader such as to correctly sample sub-tiles of a 2D texture atlas with mipmapping.

For example, Ysaneya posted such an approach back in the day.

Yup sadly she (he?) was using tex2dLod which is not available to my target hardware.