Tilemap edge problem

#1 What mode is the imagemap acquiring frames and what is the bit-depth of your image?

A screenshot would be nice as well if possible.

- Melv.

#2 Oops. Really should have put more data - sorry. Here's the imagemap description...

datablock fxImageMapDatablock2D( shroom )
{
	mode = cell;
	cellWidth = 32;
	cellHeight	 = 32;	
	textureName = "~/client/images/shroom";
};

And here's the image...

And here it is in the editor...

And here it is zoomed in (zoomed in the by the editor)...

#3 This is something that's going to be a bit of a problem I can see.

You see the grey-border around the object? That's the bilinear interpolation by the graphics card. You'll have the same effect on almost every graphics card. You see the yellowish line in the top of the middle square on the mushroom? The reason its yellowish is explained by looking at your tile arrangement. Notice that the top of that meets a green grass of the above tile? Interpolating between those pixels of red and green gives yellow.

It's a real pain in the ass really. The only real way I can see aroud this is to use nearest neighbour sampling or get imageMaps to split-up the texture into seperate textures and use texture clamping.

This problem is already down on my list though as it's been mentioned before but it does show very clearly the problem.

If you don't want to host this image and you don't mind, I can host it so that it stays here if you wish?

- Melv.

#4 Hi Melv

Thanks for the reply, this is what I thought it would be. Had these kind of issues before when doing full 3d games - one solution was to leave a 1 pixel gap around the offending image. Not sure how this would affect a tiled situation. You could maybe increase the tilesize to 33x33 pixels in the image but it actually uses the 32x32?

Like this...
The pink colour could be cleared to transparent on load. Then the uv's are 33x33 in size for a 32x32 tile. You'd have to overlap the drawing of the tiles though and that might destroy the logical co-ords. It would also mean a bit of wasted space as you'd still want to keep your tiles maps as powers of 2.

You're right. It is a bugger!

Thinking about it you might want to host those images - I just threw them on the root of our webserver to make do for now. :)

Thanks

Scott

#5 Ohhh, I had totally forgotten about that. (I don't work with OpenGL much.) That was a great explanation. That's exactly the problem I'm seeing when I talked about the funny artifacting. This would also explain the the "seams" I was seeing.

#6 Another idea to (attempt to) fix it is instead of setting the uvs to be exact bring them in by half a texel - in (very dodgy) theory the filtering wouldn't need anything from it's neighbour. ie. if your image is 128 by 128 instead of 0,0 you'd use 1/(128*2), 1/(128*2).

#7 @Luggage: Yes, I'll be looking at different ways to do this. I want it as transparent to the user as possible. Got a few ideas.

In the meantime, I'd like this post to stay informative so could you change your links to point to...

http://www.subreal.net/vids/t2dhelp/mushroomtile/edgeshowing.png
http://www.subreal.net/vids/t2dhelp/mushroomtile/edgezoomed.png
http://www.subreal.net/vids/t2dhelp/mushroomtile/pinkthing.png
http://www.subreal.net/vids/t2dhelp/mushroomtile/shroom.png

Thanks!

- Melv.

#8 Thanks Melv. Keep up the great work!

Links changed.

#9 @luggage: Doing something like you described does work. But it ends up causing other artifacts that are almost as bad. The actual pixels in the image will look like they are being squeezed. And the squeezing will change slightly frame to frame.

On the other hand, doing it with a separate texture for each image datablock frame would work very nicely. If you look at the code, the texture is being binded each frame anyway. It wouldn't effect the performace at all using a separate texture for each frame. Well at least if the size of each frame was a power of two.

#10 Was running into the same problem


got around it by doing a feather selection around the edges of the box and the exporting the png with 16.7 million colors (vs pallete based) using alpha layer transparency... downside it nearly doubles the size of the image.... this image is 64x64

heres a comparison vs the feathered one

#11 Guys,

I've bumped this problem up pretty high on the list. We've got some nice ideas over here that won't require any code/art changes on your end.

- Melv.

#12 Thats sweet! Thanks a lot Melv. Thats very exciting news for my project (which has a working title of Magic Melvin lol). :)

#13 *BLUSHES*

It's a really issue that we've got to deal with. My only concern is that we don't have to hold-off the next update too long making the modifications. We'll have to look at this carefully.

But yes, definately a very important issue to resolve.

- Melv.

#14 Having similar issues trying to use color-keyed image maps. Question:

-Does size of the color border in between tiles matter? (1px vs 3 px, etc)

#15 sorry, double post

#16 It'll affect all the imageMap 'modes'.

The updates that I want to do to the way the imageMap works will solves these issues once and for all. I doubt they will make it into the next update though as it is quite a bit of work but it will get done as it is a high priority problem.

- Melv.

#17 Someone mentioned this problem causing seams so I'm curious if this is the same issue I've been seeing. I have a map that mostly looks fine, but often when scrolling there'll be visible one-pixel gaps between tiles. The tiles are all POT and there isn't much color variation (its a top-down car game with lots of grey for road with yellow solid lines and white dashed lines).

Because the problem occurs during scrolling I'm not sure how to get an image of the seams between tiles.

Does this sound like this kind of problem?

#18 Yes, you're experiencing the same interpolation problem by the sound of it although I cannot be completely sure.

- Melv.

#19 Thanks, and I understand you can't be sure without seeing it.

Tim Doty

#20 Ancient topic, I know, but I came across this yesterday while slapping a few scrolling background layers together. I've come across similar issues in my own engines, and have a quick fix that works for me. I have done no further thought about this with respect to the T2D engine, so please note that I've done absolutely no digging around in the t2d code to see if this will have any knock-on effects. I've just blindly cut and paste from another project:

circa line 3897 of fxTileMap2D.cc (reformatted slightly here to look legible):

case fxTileMap2D::STATIC_TILE:
{
   // Cast Static Tile.
   fxTileMap2D::cStaticTileNode* pTileNode = (fxTileMap2D::cStaticTileNode*)pRootTileNode;

   // Bind with Static Texture.
   glBindTexture( GL_TEXTURE_2D, pTileNode->pImageMapDataBlock2D->getImageMapTexture().getGLName() );

change to:

case fxTileMap2D::STATIC_TILE:
{
    // Cast Static Tile.
    fxTileMap2D::cStaticTileNode* pTileNode = (fxTileMap2D::cStaticTileNode*)pRootTileNode;

    // Bind with Static Texture.
    glBindTexture( GL_TEXTURE_2D, pTileNode->pImageMapDataBlock2D->getImageMapTexture().getGLName() );

    //ADD LINES
    glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

ymmv