Tiles bleeding over

#1 You are not doing anything wrong. This is bilinear filtering messing with you. Fortunately in 1.02 Melv introduced a nice new property called inset, which helps fight this problem. Try this:

datablock fxImageMapDatablock2D(tiles2ImageMap)
{
mode = cell;
textureName = "T2D/client/images/game/tiles2";
imageCount = 16;
cellWidth = 16;
cellHeight = 16;
cellCountX = 4;
cellCountY = 4;
inset = 1;
};

The inset property restricts the size of the sprite a small amount to help fight the filtering problem.

#2 That did it. Thanks for your help Jason.

#3 I'd be interested to hear how effective this minor change is at reducing that problem. There's a more robust solution we want to get done but it'd be nice to see how effective such a simple option is.

- Melv.

#4 Well, to be honest, the filtering issue was my single biggest gripe against T2D. I wanted "great looking" 2D... unfortunately, it wasn't immediately obvious when 1.02 came out that you had added this, so I'd been pretty bummed with the look of my game.

The other day, I stumbled across this and it solved my problem perfectly! I can't tell you how that improved my opinion of T2D once the little "glitch" was gone. It was only then that I realized (potentially) an even better solution that should be code change free:

We should probably use mode="key" image maps. If people build them right (where the key color = 0x00FF00FF, then the alpha = completely transparent around the images, so every sprite now has a one pixel invisible border around it. This means you shouldn't need the inset property and sprites / tiles would look perfect. There's only one downside: texture size goes up. In my case (and Jason's here), my sprite sheets where perfectly laid out so that everything fit perfect in a single POT sprite sheet. If I take this asset change, it means I will need a larger sprite sheet.

Just out of curiousity, what do you think is the "more robust solution"? DirectX has a very nice solution to this called "Texel Bias", but as we aren't using DirectX primarily, such a fix won't help most people. I couldn't find an equivalent setting in OpenGL.

#5 Hey Melv, great fix.. works great.. :)

man cant wait for the update so I can really get started.. :)

#6 I'm assuming that "inset" is pulling in the UV's of the tile? That's a pretty common way to deal with this problem I think.

Jason, you could get what you're after by building the tiles one pixel (on each edge) smaller than you have been, and duplicating the outer edges 1 pixel larger. That's a weird way of putting it I know, hehe. What I mean is say your sheet is 64x64 and you have four 32x32 tiles. Author each tile at 30x30, then take the outermost row or column of pixels, and duplicate it. That way your tile has a padded border around it and you won't "lose" any data using inset.

I'm not sure if there is a more robust solution or not, esp if sticking with the fixed function generation of hardware. I think it's pretty much the standard way to deal with filtering artifacts at the UV borders. I believe that "texel bias" might do this same thing? I'm guesing though.

btw, does "inset" refer to pixels? IOW, 1 will mean inset the UV's one pixel all around?

#7 Is there a way to just turn off linear filtering, without messing with OpenGL/DirectX conversion? Unfortunatly I didn't have the time to have a decent look the engine since I bought but it shouldn't be hard to do that.
It would be just a "glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_NEAREST)" call with OpenGL after loading the texture. I would want to do it that way. The smudged look doesn't fit well with pixel artwork I think.

#8 @Michael
Here's a quick patch I did to be able to set nearest neighbor filtering per sprite datablock.
www.garagegames.com/mg/forums/result.thread.php?qt=28776
However, that's a patch for the old version, not sure how cleanly it applies to whatever the new version T2D is.
Oh, and it brings a whole bunch of new artefacts - swimming aliasing, which are hard to remove unless you jitter your samples, and that just opens up a whole new can of worms.

#9 Thanks Hans!
Melv says this will be a core feature in the next release, so maybe I'll wait for that (since I don't have time to code something for another 2 weeks being busy at university).
By the way, what is swimming aliasing? Is this the thing that occurs when scaling and rotating nearest-filtered images?

#10 @Michael
Plenty of visual artefacts can be cured with proper texture filtering, however a very obvious one when you use nearest neighbor filtering is that when sprites move slowly, it looks like there are glinting waves passing over the sprite. It's very noticable on things moving slowly. Not so much when things move quickly.

#11 Just FYI for melv, setting to 'inset=1' for me did not fix my issue in this case. I still have a small white outline around some tiles on my tilemap.

Interestingly enough, it only shows up around the upper tree tiles, which are on a different layer and meant to be drawn above the player. For example...