[Solved] Camera/SpriteBatch resizing conflict

[Achri]

I've been working on this for a month in my (little) spare time. I spent all of last night and all of today trying to figure it out and solutions via searching.

I am just trying to make a puzzle game similar to the puzzle games based on Shariki(http://en.wikipedia.org/wiki/Shariki).

I am building a library that allows one to create any number of puzzles within a single game. For example, you start out on one screen looking at Puzzle A. By pressing the right or left keys you go to Screen 2 or Screen 3 and see Puzzle B or Puzzle C. Each puzzle can vary in width, height, x, y, number of tiles, size of tiles, size of padding between tiles, etc.

I am still developing the framework, but I have run into this issue that I thought I had fixed a ~month ago.

On a grid of 8 x 8 tiles. Each tile can have a varying 'padding' between it and the tiles surrounding it. This padding can be specified via any number of pixels. The game will scale the tiles to keep the desired board size the same, but increase/decrease this padding.

When I create these puzzle boards, some of the tiles will have no padding, some will have the desired padding, and some will overlap and 'blend' into a darker color.

Desired look:

Normal.png (22.69 KiB) Viewed 429 times

I've found a way to re-create these lines via resizing the game while it is running:
Linear filter has dark overlapping edges:

resized2.png (17.93 KiB) Viewed 429 times

I can't add another attachment, but the Nearest filter does not have the dark overlapping edges, but instead contains tiles butting up to other tiles. So even with 'padding' some tiles will be right up against other tiles.

However. I have been working with a size of 480x800 for my game window and camera size. When I vary the number of tiles, the lines show up different times/different places due to automatic resizing of the code.

I have attempted numerous things to fix this:
1. Changing height, width, x position, y position, scaling, etc. from ints to floats and floats to ints.
2. Changing the filters on the textures from Linear<->Nearest.
3. Changing camera types.
4. Changing the SpriteBatch matrices to other things.

I finally created a bare bones application to just draw the pictures above(The full code for the main file is attached in Test.txt). Here is what I think are the major snippets:

Code: Select all

camera = new OrthographicCamera();
camera.setToOrtho(false, 550, 550);


Code: Select all

batch = new SpriteBatch();


Code: Select all

redTexture = new Texture(Gdx.files.internal("data/red.png"));
redTexture.setFilter(TextureFilter.Linear, TextureFilter.Linear);
redSprite = new Sprite(redTexture);


Code: Select all

sprite.setPosition(x * 65, y * 65);


Code: Select all

public void render() {      
    Gdx.gl.glClearColor(1, 1, 1, 1);
    Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
      
    batch.setProjectionMatrix(camera.combined);
    batch.begin();
    for(Sprite sprite: spriteContainer)
    {
        sprite.draw(batch);
    }
    batch.end();
}


There are no other references to cameras, frustrums, views, spriteBatches, etc in the test code. This is it.

Here are a couple references that I tried to use to solve this:
https://github.com/libgdx/libgdx/wiki/O ... hic-camera
http://www.badlogicgames.com/wordpress/?p=1403
http://code.google.com/p/libgdx-users/wiki/Sprites

I'm feeling really frustrated and want this library framework completed.
I don't know much of anything about OpenGL. I can do matrix calculations, but I don't know much about the graphics implementation with matrices.

Any help is appreciated.

[dermetfan]

This may be texture bleeding.
thread 1, thread 2, thread 3

[Achri]

I was excited when I might have a solution.

It still does weird things like butting tiles up to other tiles.
There should be a purposeful 1 px 'bleed' on this, but some are touching(Some are properly separated by 1px):

friends.png (21.99 KiB) Viewed 407 times

Here is my GDX Texture packer:

Pack.png (61.88 KiB) Viewed 407 times

[Achri]

I have played around with all the variables, changing one at a time. I've gone though all of the texturePacker and flipped every switch off and on.

I dropped Sprites and went to straight Textures and original single images.

I am no closer to a solution. Some lines are still 2px wide while some are 1px wide in the same screen. Resizing the screen just changes which lines are wider/thinner.

Is it possible this is an OpenGL issue? It appears on both phones and multiple laptops/desktops. I really can't see there being anything in LibGDX that would cause this to happen.

[evilentity]

Working with single pixels wont do you any good, especially when you start thinking about different aspect ratios and resolutions. 1 pixel will be almost invisible on 1080p phone. Bleed is most likely due to subpixel coordinates of your sprites during movement. I suggest working with some arbitrary units other than pixels. Say 1dp = 3px on low res and more on higher resolution. Make your tiles 10dp or something and go from there.

[Achri]

Thanks for the reply,

My tiles are actually 64x64 wide. When I build a grid of these tiles using a double 'for' loop there is a varying gap/padding between the tiles that is what looks like 1-2px.

You can see this in one of the pictures where some of the tiles have no gap at all and others have a pixel or two of a gap.

I don't think I have a bleed issue, but I'm not positive. I set my texture filters for both max and min to Nearest. I really have no clue what else I could do to make sure there is no bleed.

I played with the texture packer a lot and I even dropped the atlas method and went straight to textures. I changed the texture filters on each texture manually.

I think my Resized2.png picture was due to bleed though. Nearest filter fixed that.

[NateS]

Sorry I didn't get to this soon. You can try IRC for faster answers.

When your camera's viewport is not the same as the screen resolution, it is stretched to the screen resolution. Unless that stretching is a multiple of 2, filtering can cause artifacts, such as rows or columns of pixels getting lost or blurred. You can use a larger space between tiles or adjust your camera in resize() to match the resolution.

[Achri]

Thanks for the reply, I'm sure you are busy.

Your answer makes sense.

The width and height in my desktop application is the same as the width and height of the viewport.

So when I resize the window and the really large gaps appear, your answer explains that to me and I figured out a solution.

However, when I initiate the game with the viewport == resolution it still shows a noticeable difference in padding. This is even without resizing.

Here is a picture and the relative code:

Code: Select all

      camera = new OrthographicCamera();
      camera.setToOrtho(false, Gdx.graphics.getWidth(), Gdx.graphics.getHeight());


Code: Select all

      cfg.width = 550;
      cfg.height = 550;


You can really see the difference around the red tiles. Or is this all in my head? It seems like the jpeg compression really emphasizes it and makes it easier to see.

test2.jpg (54.61 KiB) Viewed 300 times

[NateS]

Take a screenshot so you don't have JPEG messing with it, zoom in and look at your gaps. They are probably 1px. Your screen has RGB dots that make up one pixel. If you only light one of the dots (eg red) and that dot is closest to your gap (which won't be consistent across screens, which is why ClearType for subpixel font rendering has a configuration dialog), it may appear that the gap is smaller.

[Achri]

Take a screenshot so you don't have JPEG messing with it, zoom in and look at your gaps. They are probably 1px. Your screen has RGB dots that make up one pixel. If you only light one of the dots (eg red) and that dot is closest to your gap (which won't be consistent across screens, which is why ClearType for subpixel font rendering has a configuration dialog), it may appear that the gap is smaller.

They are 1 pixel. That drives me nuts. So it may be possible that a 3 pixel gap will not be as noticeable.

Thanks for the answer.