Lines between my tiles?

35 replies [Last post]
jason.bradley
User offline. Last seen 1 year 7 weeks ago. Offline
Joined: 26 May 2011

I have seen a strange issue both in viewing the examples provided with Lime in the viewer and with the map I've created. What I have noticed is that lines appear between some tiles, they also appear and disappear as the screen moves. It looks as if the tiles are off by one pixel in some areas or such. I'm not sure if this is a known issue since I'm seeing it in the viewer examples.

Here is a screenshot of what I'm talking about:

http://imageshack.us/photo/my-images/21/linesbu.png/

Replies

GrahamRanson
User offline. Last seen 36 weeks 1 day ago. Offline
Joined: 29 Mar 2010

These lines are generally caused by the content scaling, make sure the resolution in config.lua is correct for your device.

peach pellen
User offline. Last seen 1 year 44 weeks ago. Offline
Alumni
Joined: 12 Apr 2011

Just to add to this; make sure your images are an EVEN number of pixels by an EVEN number of pixels.

This issue drove me mad as a newbie ;)

Peach

GrahamRanson
User offline. Last seen 36 weeks 1 day ago. Offline
Joined: 29 Mar 2010

And to add to that further, also try to make sure your images are powers of 2 :-)

aaaron
User offline. Last seen 28 weeks 1 day ago. Offline
Joined: 30 Jan 2011

Ahh this makes sense, I had this happen with 1 of my images as well. Thanks for the advice Peach and Graham.

jason.bradley
User offline. Last seen 1 year 7 weeks ago. Offline
Joined: 26 May 2011

@Graham
I was seeing this in the viewer example (as shown in the screenshot). I am developing for android devices. What should I set the width, height to in the config.lua for android? In my application I believe it is w=480 h=800

@Peach
My image tiles are even. I used 64x64 grid in Photoshop. It looks fine in the Tiled application.

@Graham
64x64

Once I get this resolved I should be good to go. Other than these lines showing up it is working great.

Thanks!

jason.bradley
User offline. Last seen 1 year 7 weeks ago. Offline
Joined: 26 May 2011

Well I just noticed that if I zoom in on the simulator the blinking lines go away. But I tried it on my phone and they are still there. Hmmm...

jason.bradley
User offline. Last seen 1 year 7 weeks ago. Offline
Joined: 26 May 2011

Sweet, it looks fine now. I changed the scaling to "none" in the config.

Thanks for the help!

application =
{
content =
{
width=480,
height=800,
scale = "none",
},
}

peach pellen
User offline. Last seen 1 year 44 weeks ago. Offline
Alumni
Joined: 12 Apr 2011

Glad to hear it, look forward to seeing the completed project! :)

Peach

Savarok
User offline. Last seen 2 weeks 4 days ago. Offline
Joined: 22 Feb 2011

Has this issue reemerged with the latest Corona builds as I cannot seem to fix this problem and I have tried everything lol. I have tried the latest build and still the same issue

* Have modified the .config file with all variations
* Have added @2x tilesheet and same issue, works fine on 3GS but when built/viewed on iPhone4 can see the lines.
* The files are from the tutorials are the same look fine on iPhone3G but lines on iPhone4

I am trying to develop a game for both iphone3 and iphone4 and simply cannot get past this problem for the last two weeks which is becoming frustrating.

Can someone please help or advise what else I can do ?

GrahamRanson
User offline. Last seen 36 weeks 1 day ago. Offline
Joined: 29 Mar 2010

Are you able to send your project to support@justaddli.me and I can then see if I can solve the issue?

rakoonic
User offline. Last seen 19 hours 5 min ago. Offline
Joined: 20 Mar 2011

OK this problem is caused when you are trying to display a tile at a larger resolution than it actually is, so yeah it normally shows up from content scaling.

The problem is the graphic itself and how Corona interpolates the images (and in fact several of us have petitioned to be able to remove this interpolation which would remove this problem, albeit present others).

Basically while an image is mapped to the screen on a 1 to 1 pixel basis or smaller, all is fine.
When you show the tile onscreen bigger than it is, corona chooses to try to be helpful, and smooth the graphic. By which I mean say you have in your tile a white pixel next to a black pixel, but because of zooming this takes up 3 pixels, the middle one would be grey - interpolated from the white and black.
Now this is lovely for many things, but...

Well, most tile sets have the images right next to each other in the graphic, which means that when you zoom a tile, it is interpolating from its edge pixel, into the edge pixel of the tile next to it in the source graphic.

Ruh-roh!

Fear not though, my friends, for there are solutions. I mean apart from bashing your head against the wall.

Bear in mind this won't look perfect - there really is no proper alternative except for manually choosing a correctly sized source image for the resolution of the device, but you can work around it.

Basically you need to re-lay-out your original image and do some magic in photoshop or whatever.
Let's say you have a 512x512 image with tiles of 50 pixels each.
What you need to do is space them out, giving each tile its own seperate 1 pixel border on every side.

So the top left tile would be at 2,2 instead of 1,1 and the second would be at 54,2 instead of 50, 1. The next at 106, 1 etc.
Then, and this is the tedious part...

you must duplicate each tile's edge pixel into the adjacent space available for it, followed by filling in the corner pixels of the borders with the corresponding pixel of the tile.

Boring eh?

So basically each tile now has its border repeated on each side by 1 pixel.

What this means is that at least when the tile comes to be zoomed in-game it will interpolate with the same colour as its own edge, and you won't get those silly lines cropping up.

Now, it won't look 100% correct either! But it won't look massively wrong.

A couple of further tips to avoid weirdness, is to avoid scrolling in fractions of a pixel. Whenever you come to draw a screen, always make sure the view is math.floor() or math.ceil() to an individual pixel of the device resolution. Bear in mind this may necesesite NOT using one of corona's inbuilt zoom modes (which was the first thing I ditched anyway as soon as I realised the limitations). If you don't do this, you'll see the edges of tiles flicker differently to the scrolling, simply because edge drawing of a tile is clipped to pixel boundaries, but the interpolation of the image within the tile itself is not.

@danny - because your project is just for iphone and iphone4, you have the luxury of having two very simple resolutions to work with.
What you need are 2 versions of the tile sheet image, the second one being scaled up twice as big (my suggestion would be to do it in photoshop WITHOUT bilinear or trilinear filtering, or it'll look wrong again!). Then work out which device you are on manually, and load the appropriate image, doubling the sprite sheet parameters as needed (width and height of each frame).
Since you'll now always have the right image according to screen resolution, you should never see those lines.

GrahamRanson
User offline. Last seen 36 weeks 1 day ago. Offline
Joined: 29 Mar 2010

Thank you for the very thorough explanation! I hope Ansca can get something sorted for this.

mr_x408
User offline. Last seen 2 years 38 weeks ago. Offline
Joined: 8 Feb 2011

Hey everyone I am having the same problem. I building for android devices hopefully for both tablets and phones, and well the problem I have is there is too many different phone resolutions out there for me to just manually apply the tile sheet and map file. Is there another solution for this? And ill add that not only will this problem occur when trying to scale an image to a bigger resolution then what it is supposed to be but also happens when you are scaling down the resolution.

CrucibleGames
User offline. Last seen 2 years 6 weeks ago. Offline
Joined: 24 Apr 2012

Rakoonic, thank you SO much for that extremely helpful post. My partner and I have been going a little bit crazy with the white lines between our tiles, and your suggestion of adding the border in the image made the situation a thousand times better. One of the best posts I've ever seen from a community member!

walter
User offline. Last seen 3 hours 24 min ago. Offline
Staff
Joined: 22 Jun 2009

@rakoonic, great explanation! In fact, I came across a comment elsewhere that this is "game art rule #5".

This is a universal OpenGL problem, not a unique Corona one. Anytime you are packing images onto a single texture (aka spritesheet/imagesheet), you are going to have this problem.

The good news is there are tools that help you deal with this. TexturePacker, for example, has an "extrude" option that repeats the borders of each tile/image in a spritesheet to address this exact problem.

I did a quick test using TexturePacker, and setting the "extrude" value to 2 does add a 2 pixel border that repeats the edge of a given tile. The generated size of each tile is the same, but you get the necessary padding so that the interpolation doesn't bleed into the adjacent tile/image.

walter
User offline. Last seen 3 hours 24 min ago. Offline
Staff
Joined: 22 Jun 2009

Addendum:

In terms of how this works with tools like "Tiled" (the tile map generation tool that Lime recommends), you'd want to set the margin/spacing to match the repeated border width used in tools like TexturePacker.

@Graham, I'm sending you a note offline about this to confirm.

info583
User offline. Last seen 1 year 49 weeks ago. Offline
Joined: 23 Feb 2012

With todays daily build, that introduced the 'border' property to ImageSheet, this should no longer be an issue, right?

EDIT: Worked like a charm for me! :)

walter
User offline. Last seen 3 hours 24 min ago. Offline
Staff
Joined: 22 Jun 2009

Yes, the one gotcha is that you'll want to create the image sheet correctly when you use 'border' so the image border is repeated correctly (as I mentioned above).

If you reuse an old one without the padding, your tile will be smaller on each side by the thickness of the border you specify.

richard9
User offline. Last seen 19 hours 16 min ago. Offline
Joined: 28 Feb 2011

Where is the border property covered in the documentation? Can't seem to find out anything about this...(EDIT: Oh, it's not.)

1. I'll file a bug somewhere; not having border listed in the docs is a shame for the new documentation platform.

2. I think a clearer instruction is needed for this to actually be a practical solution; I tried applying borders and had no luck getting imageSheet to work. Sadly this problem is basically as complex or more than creating masks, and there's already a page of Corona documentation for that!

a) It's not clear at all which Tiled tile set settings must be made. Spacing? Margin? Who knows?

b) I think Corona is choking on the file being power of 2 but because of the border cannot fill image with tiles (you get a bunch of blank space on the side that isn't quite one-tile wide)

Texture packer is an interesting idea but also totally untenable for tile work. Faster to do the pixel pushing in Photoshop than labor through a complete tile set disassembly in the hopes that it might make one file that can be used in Tiled.

3. Setting borders requires editing a core lime file, so that's probably something for Graham to expose in the map loader.

I think the problem is solvable for Lime but will take some time with a separate, raw project to figure out since Lime, Tiled, and Corona all need different changes at different levels for this to work.

walter
User offline. Last seen 3 hours 24 min ago. Offline
Staff
Joined: 22 Jun 2009

Starting in 860, we are now posting api docs with each daily build (http://developer.coronalabs.com/downloads/daily-builds). There is information on the 'border' property in the newImageSheet API page.

It's not a power of 2 issue. I described the issue previously on this thread.

Ensuring the borders are duplicated is something game level designers are taught to do in school. This isn't some exotic idea that we made up.

You can either to this manually in photoshop for each tile you create, or rely on tools to do this for you. TexturePacker does offer this. I don't know about others.

richard9
User offline. Last seen 19 hours 16 min ago. Offline
Joined: 28 Feb 2011

*takes a deep breath*

I'm not exactly sure what you took offence to; hopefully this post better explains what I was talking about. I'll admit one of your comments ticked me off pretty well as well, but I'll just assume it's another misunderstanding and get to the explanation:

1. "border" did not exist in the API doc as of my original post last week. ("EDIT: Oh, it's not") was not a smarmy reply, it was a matter or fact reply after I spent some time searching through coronalabs.com to see if I was mistaken. Clearly it's fixed now, so we're all the better for it, the end.

2. I simply suggested a guide/tutorial similar to the excellent one already there for masks, since both have similar, non-intuitive solutions. It doesn't sound like Corona Labs is particularly interested in blog volunteers but I'd write it myself if asked.

3. Explaining the power of 2 guess; clearly I was reaching for words to describe what was happening, but now I have a better idea what was going on:

Original file: 192x96, 8 tiles (so, 4x2, each tile is 48x48)
Modified file according to rakoonic's solution: 200x100 (50x50 tiles to account for a 1px border)
Modified file with power-of-2 canvas: 256x128 (still 50x50 tiles but with some junk space)

I proceeded to add the border value to Lime-tileset.lua (manually; Lime isn't really built to accept borders yet) and got this:

Incorrect number of frames (w,h) = (48,48) with border (1) in texture (w,h) = (256,128). Failed after frame 9 out of 10.

Yes, that is an obvious assert message that Corona is using simple image sheet mode and obviously can't read in an invisible tile that is not even 48x48 large. It confused me at a glance because I mistakenly assumed Tiled and/or Lime would only deal with the tiles specifically being used as opposed to simply reading in the strip.

But let's say we use the 200x100 tile set instead. In Tiled, we set the spacing between tiles to 2px. What happens?

TIled: Looks fine!
Corona? Loads fine, no error messages.
Lime? Not so much. The map is there, but it looks like a chessboard at any resolution.

After trying a dozen different combos (a long and tedious process since you can't preview anything or do a 1-for-1 tile set replacement) the correct Tiled Tileset settings are:

Tilesize: The original tile size before making the bleed/extrude modifications. (i.e.: 48x48)
Margin: 1px
Spacing: 2px
Offset: 0/0px

(just make sure you add this to options to look like this on lime-tileSet.lua or it won't look right no matter what you do...)

1
2
sheetContentHeight = self.height, -- need the comma here
border=1, -- border size per tile

4. We're both right on Texturepacker. It does work, as you say, to quickly extrude tiles. But unless I'm missing some feature, TP cannot distinguish between tiles within the same file; they all have to be separated into separate .png's first. That's fine if you only have a few, but, as I said, untenable at 50-100+. Instead a google search suggests imagemagick:

ImageMagick: convert -crop 48x48 myoriginal.png mytiles_%d.png

...might do the trick?

rakoonic
User offline. Last seen 19 hours 6 min ago. Offline
Joined: 20 Mar 2011

In case people come across this thread, I've uploaded an image showing 3 different variants of tile images that can show the various effects of tiles set up correctly or incorrectly.
Click on the image to see it fullsize and get a better idea of what is going on.
Note the pole at the right for probably the clearest visuals of what is going on.

http://imgur.com/a/wcBMk#17

SimonBurford
User offline. Last seen 1 week 3 days ago. Offline
Joined: 7 Dec 2010

richard9,

Thanks for the useful information!

To test your solution I created a 200x100 image with 8 48x48 tiles within it, each with a 1px border. I then added the tileset to Tiled using the settings you provided. And finally, I made the changes to lime-tileSet.lua.

However, when I test this in the simulator I get the following error:

lime-tileSet.lua:198: Incorrect number of frames (w,h) = (48,48) with border (1) in texture (w,h) = (200,100). Failed after frame 9 out of 9.

Am I doing something wrong?

richard9
User offline. Last seen 19 hours 16 min ago. Offline
Joined: 28 Feb 2011

Hey Simon,

Believe it or not, the most common reason for that specific error is that you only updated the original tileset and didn't also edit the @2x tileset (or vice versa). I'm pretty sure that would fail the sim unless it is running specifically the 3GS skin. (In one troubleshooting moment I just dropped all @2x tilesets from my project until I figured it out...)

Beyond that there are lots of possible problems. Hard to say exactly what to look at but step one should always be close the files, check their dimensions, and see if it loads up alright in Tiled.

SimonBurford
User offline. Last seen 1 week 3 days ago. Offline
Joined: 7 Dec 2010

Thanks for the additional information, richard.

I double-checked the dimensions and everything is correct, and it appears great in Tiled.

I didn't have an @2x tileset in my project folder, but I tried adding that as well but it didn't help.

Would you be able to have a quick look at the files? Maybe I'm missing something. Here they are: https://www.dropbox.com/s/0twcikt5rykpzks/tileLines.zip

For obvious reasons I didn't include the Lime files! :P

richard9
User offline. Last seen 19 hours 16 min ago. Offline
Joined: 28 Feb 2011

1. You didn't modify the tileset image; as rakoonic et al explained when you take your tileset from 48x48 to 50x50 like that, you have to duplicate the edge of each tile into the new lines.

1-1: Load vomit.png in Photoshop
1-2: Your example tiles are easier to fix; just add a 1px ring of the tile color around each tile.
1-3: When done, save a copy out double sized to make the new @2x file.

2. Using that package I have no error message at all (once I add in Lime 3.5beta, of course) That being said, there is obviously something really odd with the tile display going on; it's as if the tiles are squished together a bit. So...

2-1: I ripped out my lime directory and re-added vanilla Lime 3.5beta, just in case.
2-2: On lime-tileSet.lua:194 I added a comma at the end, and then hit enter
2-3: On the new line :195 I added border = 1,
2-4: CTRL+S to save ;)

Now it runs fine. No error message (apart from that stupid "no ui.lua found" warning), which can be removed elsewhere. The map looks exactly the same on 3GS and 4 as it does on Tiled.

So either:
a) you have a problem somewhere else in your code (or maybe your Lime modifications)
b) it's a side effect of not expanding the tile by 1px

For reference, here's what the options table in lime-tileSet.lua should look like, exactly:

1
2
3
4
5
6
7
8
9
                        local options =
                        {
                                width = self.tilewidth,
                                height = self.tileheight,
                                numFrames = self.tileCount,
                                sheetContentWidth = self.width,
                                sheetContentHeight = self.height,
                                border = 1,
                        }

lKinx
User offline. Last seen 8 weeks 6 days ago. Offline
Joined: 11 Nov 2011

I believe this is the issue:

The way Lime calculates self.tileCount, it doesn't take the border into account. If your tile set doesn't have a ton of frames or the tiles are large, it may not be able to add an extra tile out of all of the borders. I had 25 30x30 tiles with a border, so in the sprite sheet each tile was actually 32x32. Lime ended up thinking like this: a 256x128 image with 30x30 tiles... Hmm... (256 / 30) * (128 / 30) = ~36 tiles. As a result, that failure error occurs. I haven't actually had the time to go to where self.tileCount is calculated and adjust it, but when I figure out a solution I'll get back to you guys. Or someone else can work on the fix and tell us how to do it as well. :P

SimonBurford
User offline. Last seen 1 week 3 days ago. Offline
Joined: 7 Dec 2010

I still don't understand why this doesn't work, I followed your instructions to a tee :(

Here's what I did:

1) Loaded the tileset image into Photoshop and added the 1px ring around the tiles, as suggested in 1-1 and 1-2.
2) Saved out an @2x version of the modified tileset image, as suggested in 1-3.
3) According to the steps that you took, it should be working right now, but it isn't. Damn!
4) Recreated my level, just to be sure. I also made sure to get the margin (1px), spacing (2px), and offset (0/0px) settings correct when importing the tileset. Everything looks great in Tiled.
5) Re-downloaded the Lime 3.5 beta and added the fresh files to my project folder.
6) Opened the brand new 'lime-tileSet.lua' file and copied your options table into the correct location.
7) Does it work? Nope nope nope! Still getting the exact same error. D:

Is there somewhere that I can email you a copy of the project which includes the Lime files? It will be interesting to see if my complete project does / doesn't run on your end. I'm pretty sure there's absolutely nothing I'm doing wrong.

Thanks for the continued help!

lKinx
User offline. Last seen 8 weeks 6 days ago. Offline
Joined: 11 Nov 2011

See my explanation two posts above as to why that error is occurring. I'm pretty sure that's why it's happening.

In reality, your sprite sheet has 8 tiles. But since (200 / 48) * (100 / 48) = 8.68 = ~9. That's where the 9 is coming from. Lime doesn't realize that the borders don't count towards a tile. I bet the simple fix would be to go where self.tileCount is calculated, and add 2 to the tile size so that it reads [200 / (48 + 2)] * [100 / (48 + 2)] = 8. Corona should know how to worry about the border after that, and the problem should be fixed. :D

richard9
User offline. Last seen 19 hours 16 min ago. Offline
Joined: 28 Feb 2011

I disagree; while your math is sound, I don't believe Lime is actually using filesize to determine the number of tiles (based on what I can tell, it's actually pulling that information from the Tiled file during the import phase). But I'll take a closer look later today.

Regardless, I didn't run into his problem despite using his own source files and assets so I'm inclined to believe it's something else.

Simon which version of Corona are you running?

(namenonumbers) -at- moogle dot net

SimonBurford
User offline. Last seen 1 week 3 days ago. Offline
Joined: 7 Dec 2010

Thanks for the help.

I tried your solution, lKinx, and the error is gone! :) Which is really confusing, because richard9 didn't run into this problem at all, even when using my assets.

I made a slight change to line 186 in the 'lime-tileSet.lua' file.

Original line 186:

1
self.tileCount = ( self.width / self.tilewidth ) * ( self.height / self.tileheight )

Modified line 186:

1
self.tileCount = ( self.width / (self.tilewidth+2) ) * ( self.height / (self.tileheight+2) )

richard9:

At the time of my first post I was using a week old daily build, but I tried downgrading to the latest public release and now I'm using the latest daily build. No version has had an effect on the error.

Emailed you my project files.

richard9
User offline. Last seen 19 hours 16 min ago. Offline
Joined: 28 Feb 2011

Simon, I tried your project; literally just opened the zip and it works; I'm still running 883 but I haven't heard of any change Corona side to the border stuff since then.

I'd look into it more but it seems Corona Labs completely changed how builds work and now it's incompatible with SublimeText2...so I need to figure out a workaround there first.

EDIT: Well damn, they really made a mess of this, I understand this is probably related to the terminal changes but now it needs an install guide so I know how to use Corona at all on OSX.

Anyway I tried to manually run your program from the zip directory and it runs fine, no error message on the terminal apart from the usual ui.lua nonsense

SimonBurford
User offline. Last seen 1 week 3 days ago. Offline
Joined: 7 Dec 2010

Odd! Hopefully we can figure out at some point why the error is occurring. Maybe its a difference between the Windows / OSX versions of the simulator?

For now lKinx's solution works great.

richard9
User offline. Last seen 19 hours 16 min ago. Offline
Joined: 28 Feb 2011

Hey Simon,

I just tested your zip package on Windows, and got exactly the error message you described. So no, you were not going crazy! ;-)

I really, really insist that you file a bug with Corona Labs. It's easy (there's a link at the top of this website!) and you can submit in like two minutes if you just attach the zip file you sent me. (I believe it will insist you attach some code as well; just attach main.lua there but include the exact zip file you sent me in the "additional attachments".)

Don't worry about your file contents; obviously they work with Lime from time to time; the key here is just to explain that there is clearly something broken in the Windows build that is *not* broken in the OSX build. Since all they have to do is try to run the project files in the zip it should become apparent to them in like 2 seconds. :-)

(I'd file it for you, but it's not my code...)

SimonBurford
User offline. Last seen 1 week 3 days ago. Offline
Joined: 7 Dec 2010

Thanks for confirming that I'm not going crazy, richard9. ;)

I submitted a bug report as you suggested.

Perhaps someone should put all of this information into a new post / thread so that others don't have to wade through so much information to extract the necessary bits?

Viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.