Libgdx Texture Array because of bleeding

Newbie & Debugging Questions
#1

I’m bleeding… you know, the usual. Even with Nearest there is enough bleeding for it to suck hard.
padding is… not an option, changing all those tilesets changing the logic, and then the inconvenience in the map editor and all that, because tiles are no longer side by side. Just no =/

So it really appears Texture Arrays / GL_TEXTURE_2D_ARRAY is the way to go.
However I’m not too big on OpenGL, in fact I’m using 100% libgdx right now, no direct calls, at least nothing big.
The question is how to integrate an OpenGL Texture Array with Libgdx ?

#2

Hmm this is the method I used for my games…


	private void set(SpriteSheet sheet, float x0, float y0, float x1, float y1) {
		float ph = 1f / sheet.width; // texture pixel width
		float pv = 1f / sheet.height; // texture pixel height

		int bleed = 8;
		this.x0 = x0 + ph / bleed;
		this.y0 = y0 + pv / bleed;
		this.x1 = x1 - ph / bleed;
		this.y1 = y1 - pv / bleed;
		this.sheet = sheet;
		
	}

Not sure if this works with all texture sizes… Mine was 256x256 with this method.

#3

have been using pixel values for my tiles (TextureRegions) until now

not sure why that code works for you, I guess you’re just lucky with the rounding issue there

Also Linear filtering should still not work, right ?

#4

Linear filter will only make bleeding worse, as it smudges out the edges. Here is how my code works.

Not sure if this is the best representation of what I was trying to achieve with this code, but it seems to have worked by removed texture bleeding and not altering the shape of the texture.

In this picture gray grid is a texture of 8x8 texels. Red line is the outline which is passed into my method I described earlier.
Green line is what my method does.

#5

I suggest using individual images in Tiled and then pack your images into an atlas for use at runtime (see AtlasTmxMapLoader). This allows you to change how the images are packed (padding, which images are on what atlas page, etc) without breaking your Tiled map.

Otherwise you could maybe fork libgdx, see the Mesh constructor which takes a VertexDataType. You’d need to add a new VertexData implementation.

trollwarrior1’s approach is even simpler, just move UVs one texel toward the region center. This will stretch your images but filtering won’t pick up neighboring regions (it will pick the texel you excluded).

#6

Not using Tiled as I need way too many features and customization that would be very hard with tmx and the editor / that the editor doesnt have anyway.
So I wrote my own tile system and especially very elaborate editor.
Even if I would be using Tiled: separate images for tiles… thats a nightmare for the artists. Every time there is something bigger than the tilesize they would have to cut it up, and then you would have to somehow pack it perfectly onto the tileset which happens automatically.

Thats for the pointer.

Gotta try it out, but I would imagine it looks like crap :o

#7 

			float adjustX = 0.25f / texWidth;
			u += adjustX;
			u2 -= adjustX;
			float adjustY = 0.25f / texHeight;
			v += adjustY;
			v2 -= adjustY;

Seems to work very well.
Of course I get greedy and try even linear filtering now. Round camera positions and certain rounded zoom values do work… hm

#8

Tiles in libgdx are not limited to a specific size. You don’t need to break a large image up into many small images, you can just use the large image.

#9

Well in my engine and physics there has to be a fixed tilesize.
Good to know though, if I ever wanna use tmx for something smaller

#10

You can still have a standard tile size for placement and the collision layer. The way it works is the image for a tile can simply be any size. Makes it much easier to build maps. FWIW, Super Spineboy does this (using Tiled but the idea is the same).