Artifact/Tearing Problem with LibGDX

OpenGL Development
#1

Hi JGO!

I’m currently working on a simple side-scrolling game for my software engineering class. I’ve been working on the graphics lately and being able to resize the screen while having the aspect ratio stay the same. Everything is working fine with the resizing, but once I begin resizing it, I get weird lines between my tiles. Here’s a picture:

I checked out this thread below which seemed similar, but most of the proposed solutions did not seem to work for me.

I tried rounding the camera coordinates before sending it to the SpriteBatch but that didn’t help. I’m loading the tiles from a single Texture and splitting them up into an array of TextureRegions, but the pink color of the line artifact is from a neighboring tile to the dark purple one seen here. If I change the pink tile to gray, sure enough the line artifact changes gray. I tried loading the texture with different filters but nothing worked. I feel like it must be something with the texture though because of the way its sampling the texture outside of its region.

Now that I think about it, I haven’t really seen many games allow you to stretch the window to whatever size you want. Is this why perhaps? Maybe I should just have a couple different scales that are stable, to scale the resolution up by? Here is the resize method from my Game class (implementing ApplicationListener from gdx). The code is taken off a tutorial I found, I can try to find the link for it if anyone wants.

	public void resize(int width, int height) {
		float aspectRatio = (float) width / (float) height;
		float scale = 1f;
		Vector2 crop = new Vector2(0f, 0f);

		if (aspectRatio > Screen.ASPECT_RATIO) {
			scale = (float) height / (float) Screen.SCREEN_H;
			crop.x = (width - Screen.SCREEN_W * scale) / 2f;
		} else if (aspectRatio < Screen.ASPECT_RATIO) {
			scale = (float) width / (float) Screen.SCREEN_W;
			crop.y = (height - Screen.SCREEN_H * scale) / 2f;
		} else {
			scale = (float) width / (float) Screen.SCREEN_W;
		}

		Gdx.gl.glViewport((int) crop.x, (int) crop.y, (int) (Screen.SCREEN_W * scale), (int) (Screen.SCREEN_H * scale));
	}

Thanks for your help!
-Bukky

#2

Looks like texture bleeding to me. Do you have bilinear filtering enabled? What is the resolution of your texture?

#3

Ya, from a cursory google search that’s probably what it is, I didn’t know the proper term. I’m using a 128x128 texture with 32x32 tiles, here it is:

I’m pretty sure LibGDX defaults to Filter.Nearest, but I made sure when I loaded the texture that is to be split into multiple TextureRegions, I set its filtering to Nearest. Though I’m unsure if that’s the proper way to do it.

#4

I don’t have that much experience with LibGDX but could you post your tile rendering code? Also, could you tell me how the bleeding behaves? Does it shimmer when you move the camera too?

#5

It was happening with any of my TextureRegions I found out, and yes it shimmered when the camera moved, as well as appeared in different locations. I ended up trying out this technique below and the bleeding is gone, though I tweaked the coordinates of the region.setRegion line a little bit (from .5f to .01f), and I don’t understand whats happening exactly. It seems like it is just tightening up the region by a subpixel amount. Though when it was adding and subtracting .5f it was shaving of a whole pixel in most cases so my tiles had a line of transparent pixels in between each.

http://www.wendytech.de/2012/08/fixing-bleeding-in-libgdxs-textureatlas/

#6

I don’t have any experience with libGDX. How are you drawing your sprite?

#7

you need to duplicate the borderpixels of each tile. libgdx’s texturepacker can do that for you.

#8

Really? He shouldn’t need to do that in my opinion… >_>

#9

oh it can ? need to read the options again I guess

Edit: Ah yes and I can see that this is default actually… edgepadding

#10

Ya I was using the texture packer and it was doing that by default, but I didn’t feel like splitting up all my tiles and animations into separate images. This other fix looks good enough I think.