Would you try this:
http://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2016/07/gaps.zip
Try test1 and test2 (starts on test2).
Do you get gaps? If not, I included the texture packer source file, but I used these settings if you have trouble loading tiles.tps:
Please note: I failed to use adaptive scaling in the above code. I’m so used to using letterbox, so you may want to change that and re-test. i.e. set my code to use adaptive and see if you’re good to go.
In any case, if the problem re-occurs, this should give you a simple test case to work and experiment with.
I do see “white flashing” on edge of tiles while the map pans, for both test1 and test2 (tried a few simulator devices with 100% zoom)… I am hoping this is not another bug…
I manage to produce a case where black edge doesn’t appear, I will dig deeper on why… This is taking more time than I expect for sure…
Are you including the LaunchImages for iphone 6 6+ in the project?
> Are you including the LaunchImages for iphone 6 6+ in the project?
No, I didn’t, but why does it matter?
To All,
I would think my problem is either (1) my tile being positioned slightly off the designated position, (2) image sheet select the frame slightly off the designated coordinate; so the background black color show through the gap (hence the 1px black gap).
If my tileset comes with gap between tiles I would assume I need extruding, but they didn’t; I have added gaps to tileset but problem persists.
The question is, why does it only happen on certain layer? I checked my map layer data and their properties are no different from others (besides opacity, but I have other tile layer with same opacity not being affected).
I tried extruding (up to 4px for each tile) as well, the black gap still show up on iOS Device, what the hell is wrong with my code? how come it doesn’t show up in the SDK simulator? I need a reduced test case…
Also I am working with pixel art, so even if isImageSheetSampledInsideFrame works, it really isn’t a good option for me, as it can cut the edge pixel in half and render things weird if you are not careful…
I was remembering this thread about visual artifacts on iPhone 6/6+ and iOS compatibility mode so I thought it might be worth to try to add the launchImages and see if it solves…
https://forums.coronalabs.com/topic/61654-tableview-line-width/?hl=%2Bdefault+%2B6%2B#entry331493
Are you sprite sheets JPG or PNG? I’d go with PNG.
Is your ‘tween’ color black or transparent? I’d make it transparent.
Just some ideas, but I’m mostly shooting in the dark.
I do agree, you need to create a minimal test case that reproduces the issue, then when you resolve that, try it in your game. Solving in situ is a strong temptation, but often a bad idea.
One little known option is this:
display.setDefault( “isImageSheetSampledInsideFrame”, true )
This offsets UVs by half a pixel within the sprite sheets.
I think this is going to the be something rather difficult to reproduce, but I am seeing something interesting:
So I am going to reproduce the issue in that direction…
But I still need to figure out the offset error on my roof layer, where the problem is not black edge, but off-by-1px sprite selection from image sheet, it’s also an interesting case: because it’s loaded the same way as every other layers, and only some of tiles are affected.
Basically, fun time with Corona 
PS: I should change the post title at this point, but not sure how to do this…
I can see how that might affect my layer rendering, even though I think compatibility mode is explicitly UI related. But I will add that back in just in case. Is there any way to add launch images to a directory/sub-folder, or do we have to have every image at the root?
EDIT: added but it didn’t resolve my off-by-1px issues unfortunately.
I have found a semi-ultimate answer to this: just create a new tileset, a new layer, move the exact same tiles onto them, and do your layer again.
And BAM, no more off-1px or sub-pixel rendering problem on iOS.
Does it imply a bug somewhere in the Corona SDK? Yes.
Can I find an easy reproduction test for it? No, I tried, it only happens when you have a large number of tiles and layers.
So guys, if you are absolutely stuck, and tried all my previous solutions: try re-do your layer and tileset.
I did find a problem in the past with very large tile source images, due (I assume) to some kind of rounding error from integer pixels to float UV coordinates - if I recall it occurred when tile set images were larger than 1024x1024 pixels (causing tiles further into an image than 1024 pixels in any axis to be slightly offset). Does this correlate at all to the images you are using? Also, this was a long time ago, so maybe it isn’t an issue any more.
I thought I posted some other possibilities in the other thread, but apparently they never survived the dodgy internet from my phone while on the bus, so I’ll try to remember what I suggested elsewhere.
At least 2 affected tilesets are 256 x 1280 and 256 x 1728, so it’s possible.
I would like to know why this isn’t mentioned on documentation… Is it iOS only?
EDIT: Case 46684 is opened for this issue, if they couldn’t fix it, I am hoping at least we can ask them to update a warning in the newImageSheet documentation?
@rakoonic, slight tangent on precision (i.e. probably not relevant to bitinn’s issue), but for larger images, the UV’s default to mediump (https://docs.coronalabs.com/guide/graphics/customEffects.html#precision-qualifier-macros) which is device-dependent.
You can override them to higher precision as described here: https://docs.coronalabs.com/guide/basics/configSettings/index.html#shaderPrecision
In addition, if memory serves, you can also set different precision for each macro separately rather than setting them globally for all macros as currently documented.
This gives you more flexibility to selectively choose higher precision which generally increases the GPU cost in the shader (so only increase if you really have to):
application = {
content = {
shaderPrecision = { P_UV = “highp”, P_COLOR = “highp”, },
},
}