on 25-06-2012 01:01 AM
scene.Camera2D.SetViewFromWidthAndCenter(750, new Vector2(400,250));
When I call this line, all my tiles are getting outlined. How do I disable this from happening.
on 02-07-2012 12:12 PM
02-07-2012 11:38 PM - edited 02-07-2012 11:41 PM
scene.Camera2D.SetViewFromWidthAndCenter(250, new Vector2(400,250));
This line of code changes the bottom right image (default) to the image on the top left.
I never call scene.Camera2D before this.
Create the sprites using this, no issue until I touch the camera.
var spriteTile = new SpriteTile(_textureInfo);
spriteTile.TileIndex2D = new Vector2i(x,y);
spriteTile.Quad.S = new Sce.Pss.Core.Vector2(82,82);
on 03-07-2012 05:41 AM
I'm interested in hearing what causes this too. I've seen to a much less pronounced degree in my game, oddly enough also in a scene with isometric tiles.
It's not that the tiles are outlined (look at the verticle line running up though the airport). My theory is the coordinates of the adjoining tiles are close but not completely touching, causing a sliver of background to show through.
Hopefully someone with more OpenGL experience can chime in here.
on 30-08-2012 07:23 AM
I'm noticing this in my game now, too. It's only when I change the viewport size, using that same function, to anything other than exactly fullscreen. Changing the viewport back to exactly fullscreen makes it go away. I was hoping to utilize this for compatibility between screen sizes, though.
Also, the gaps in tiles sometimes seem worse towards the edges of the screen, and OK in the center, as if looking at a sphere. It's not the background shining through cracks, either... there is what seems to be white and green lines vertically. Horizontally, there appears to be a thin slice of one of my tiles running the entire length.
Now that I think about it, the white and green are likely strips of my tiles too. Really weird, mainly because towards the center, there is less of this effect, regardless of which tiles are now at the center of the screen.
RawSpriteTileList here too... I really hope something can be done, because tweaking the viewport is a good way for me to handle varying screen sizes without making major tweaks to my code.
on 30-08-2012 03:06 PM
Well when someone changes the viewport changes the matrix from projection to screen transform(yes there is a matrix transform there too, well a space change in Algebra). Something I notice reading the behaviors you have, seems that change of viewport is not the standard viewport change!!!, seems more like its touching the porjection matrix too.
About OpenGL, changin the viewport changes the size of the area of the pixel will be mapped, but nothing else. But OpenGL it's only a standard specification the GPU vendor make the code for that, so the behavior will change from vendor to vendor.
About the cracks well like YadastYakuza wrote, since each tile seems a quad with no shared vertices(strange indeed.. why?) I agree with him about why you see does lines..change the background color to see if this correct.
on 30-08-2012 11:45 PM
It isn't the background shining through the cracks. It does seem like there is a floating point problem, and you'd expect to see the background through the discrepancy... but what you see is bits of the texture2D in the RawSpriteTileList itself... it's like the RawSpriteTiles themselves are no longer perfectly divided into the RawSpriteTileList Texture2D/Textureinfo whatever.
It's definitely not the background shining through.
on 31-08-2012 06:32 PM
If that so..could be how the texture border its set + texture filter...try to test changes over TextureFilter and TextureWrap.....thinking twice...since this is a 45deg camera view and you have 2D sprites...could be some math tile center problem like you wrote....check filters first just to discard possible issues there.
31-08-2012 10:19 PM - edited 31-08-2012 10:20 PM
Oh, how I wish the OpenGL specs defined the default Texture wrapping to be ClampToEdge...
In a way, Mojotron, you are right, it is an issue with floating point accuracy, but in this case, there is no accuracy between pixels in a screen for the GPU to work on.
If you are using a 2D grid based renderer, your tiles need to be perfectly screen-pixel aligned. If they are not, the GPU will try to choose the closest pixel available and render to that. By doing this, your UV coordinates might change. In GameEngine2D, your UV coords are from 0-1 (or from a Tile to the end of a tile), after this GPU pixel recalculation it is possible that the 'closest' pixel in your texture, might end up being outside your expected tile.
Using WrapMode ClampToEdge and disabling Texture Filtering like AlexMcDev suggested should fix the worst part. Do note that if you are using decimals in your sprite position, you will always have some degree of pixel bleeding! I found that the emulator behaved slightly different from the Vita considering non-screen-pixel aligned quads (the vita did have some pixel bleeding, while on the emulator it seemed fine).
on 03-09-2012 12:08 AM
Thanks a ton guys, disabling the TextureFilter improved the appearance dramatically, but at certain viewport sizes there are still lines, though far far less of them. Setting the clamp mode didn't seem to do anything though.
About decimals... I use 32x32 pixel tiles, which divides evenly into the Vita's 960x544 screen size. When the viewport is set to 960x544, is it working perfectly because the actual screen is that size, or because the tiles divide evenly into the viewport dimensions?
I may be overthinking this (which I shouldn't do because I'm no expert) but if you literally need screen-pixel alignment, and wanted the same amount of world space shown regardless of the actual screen size, and that amount of world space doesn't share the tile factor with the screen dimensions... this outlining will occur? Wouldn't that make device compatibility a nightmare?
Website ©2013 Sony Computer Entertainment Europe
All content, game titles, trade names and/or trade dress, trademarks, artwork and associated imagery are trademarks and/or copyright material of their respective owners. All rights reserved. [more info]