[Solved] Camera/SpriteBatch resizing conflict

Anything libgdx related goes here!

[Solved] Camera/SpriteBatch resizing conflict

Postby Achri » Sat Nov 23, 2013 10:22 pm

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
Normal.png (22.69 KiB) Viewed 538 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
resized2.png (17.93 KiB) Viewed 538 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.
Attachments
Test.txt
(3.33 KiB) Downloaded 21 times
Last edited by Achri on Sun Dec 08, 2013 6:07 am, edited 1 time in total.
Achri
 
Posts: 26
Joined: Thu May 23, 2013 2:17 am

Re: Camera/SpriteBatch resizing conflict

Postby dermetfan » Sat Nov 23, 2013 11:12 pm

This may be texture bleeding.
thread 1, thread 2, thread 3
dermetfan
 
Posts: 375
Joined: Fri May 03, 2013 8:57 pm

Re: Camera/SpriteBatch resizing conflict

Postby Achri » Sat Nov 23, 2013 11:59 pm

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
friends.png (21.99 KiB) Viewed 516 times


Here is my GDX Texture packer:
Pack.png
Pack.png (61.88 KiB) Viewed 516 times
Achri
 
Posts: 26
Joined: Thu May 23, 2013 2:17 am

Re: Camera/SpriteBatch resizing conflict

Postby Achri » Wed Nov 27, 2013 1:00 am

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.
Achri
 
Posts: 26
Joined: Thu May 23, 2013 2:17 am

Re: Camera/SpriteBatch resizing conflict

Postby evilentity » Wed Nov 27, 2013 9:59 am

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.
Hey you! Check out my game Super Flying Gentleman on Google play Thanks!
evilentity
 
Posts: 1162
Joined: Wed Aug 24, 2011 11:37 am

Re: Camera/SpriteBatch resizing conflict

Postby Achri » Thu Nov 28, 2013 3:23 am

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.
Achri
 
Posts: 26
Joined: Thu May 23, 2013 2:17 am

Re: Camera/SpriteBatch resizing conflict

Postby NateS » Thu Nov 28, 2013 7:57 pm

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.
NateS
 
Posts: 1965
Joined: Fri Nov 12, 2010 11:08 am

Re: Camera/SpriteBatch resizing conflict

Postby Achri » Fri Nov 29, 2013 4:43 am

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
test2.jpg (54.61 KiB) Viewed 409 times
Achri
 
Posts: 26
Joined: Thu May 23, 2013 2:17 am

Re: Camera/SpriteBatch resizing conflict

Postby NateS » Fri Nov 29, 2013 1:08 pm

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.
NateS
 
Posts: 1965
Joined: Fri Nov 12, 2010 11:08 am

Re: Camera/SpriteBatch resizing conflict

Postby Achri » Sun Dec 08, 2013 6:06 am

NateS wrote: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.
Achri
 
Posts: 26
Joined: Thu May 23, 2013 2:17 am


Return to Libgdx

Who is online

Users browsing this forum: No registered users and 10 guests