Visible bounding boxes around tiled backgrounds?

Ashley answered one of my posts the other day and recommended I use sprites and tiled backgrounds instead of painting a whole detailed level. As per the "not wasting memory" blog.

I've started working on this and have noticed an issue. Tiled background images all end up showing a bounding box around them as per this picture.

Is there a way to get rid of this or have I somehow done something wrong?

<img src="https://m2r9qg.dm1.livefilestore.com/y2pt8Fl6tvIWr1lDOHg8VE0LBeNl9dm82Fl5KZy23kPf5R8UNoLwSZgvp7OEXjyCVERllZGaD4jDxmZECXlyHP70ykzKnYlpdGdFY_6VW0mSsk/Tiled%20background%20border.JPG" border="0" />

(It's a very early test of tiling/sprites btw to see if it'll work for me)

Hmm, it appears to be a bug. <img src="smileys/smiley18.gif" border="0" align="middle" />

I've worked out that it seems to be replication of roughly half the bottom line of the image. If I remove the bottom row of pixels I can work around it, though that's a bit of a pain.

I suppose it could be a designed in overlap to help with tiling but really if it's pixel perfect, it shouldn't need it.

Having issues with the software crashing too since the recent update, don't recall having issues before. <img src="smileys/smiley11.gif" border="0" align="middle" />

Hi,

I confirm this bug, been there for at least 5+ beta releases - similar workaround used, I make transparent the topmost row of pixels and the problem disappears.

Greg

Infact this is not a bug.

The texels from the bottom row interpolate with the upper row which in your case is transparent. Since we are talking filtered textures, you will not get rid of this effect unless you switch to point sampling.

rock on,

Michael

Hi Michael

I tried switching sampling methods and turning smoothing on and off, none of this had any effect.

At least it's designed like that and not a bug, is this feature documented anywhere that you know of?

It's a bit of a pain that I can't turn it off for certain textures but I can work around it.

Be sure to use "Fullscreen in browser : Letterbox integer scale" with point sampling this should fix your problem.

Your workaround is a common method to get rid of that nasty half pixels btw.

rock on,

Michael

Here is a post where you can see Ashley's explanation.

http://www.scirra.com/forum/r106-lines-around-tiled-backgrounds_topic58776.html

It's not a bug, it's the bottom row of pixels wrapping back to the top. It's just how computer graphics work, nothing specific to Construct 2 here.

Workarounds:

• try using Pixel Rounding
• try using Point sampling
• if both the above are on and neither fix it, using Letterbox Integer Scale instead of Letterbox Scale should definitely fix it
• or just add a row of transparent pixels along the bottom of the image, so that transparency rather than image content wraps around to the top

Re: crashes - make sure your graphics drivers are up to date, that's the #1 cause of crashes in C2. If that doesn't fix it, report any reproducible issues to the Bugs forum.

It's not a bug, it's the bottom row of pixels wrapping back to the top. It's just how computer graphics work, nothing specific to Construct 2 here.

Not in a games context but I've been working with computer graphics / images for about 20 years now and I've never come across that before. I'm assuming you mean just in the context of games graphics and tiling images but I'll take your word for it - it's clearly intentional. <img src="smileys/smiley1.gif" border="0" align="middle" />

The last time I programmed a game and used tiled backgrounds was on the Spectrum 48k iirc, I may have some catching up to do.

The workaround: add an extra row of pixels to the image, or resize the image ever so slightly smaller. For example, make the image 32x33 to add an extra row of pixels along the bottom, and make them the same color. Or, just resize the Tiled Background to be e.g. 64x31, so the last row of pixels doesn't wrap around. Or, just position the other backgrounds to slightly overlap and hide the seams.

OK, just to clarify before I start altering all my images then;

Power of two images are recommended for tiling aren't they so if I use a 32x33 image, won't that occupy the space of a 64x64 one being over the 32x32 size?

If I went a little smaller instead, how does that prevent the bottom row from wrapping - does it only wrap with power of two sizes?

Thanks!

Oh - crash wise, drivers are up to date etc. I think it's always when previewing and then switching back to the C2 window but I'll make notes and bug it.

The tiled image always has a row of anti-aliased pixels along the edge between solid and transparent edges. I doubt Ashley ever wrote anti-aliasing code, I believe it happens in the graphics card. (Anti-aliasing has come a long way since early games.)

Outside the game your image holds the source data to tile. During runtime your image size is a window showing a piece of that infinite tile.

So you have to see that anti-aliased row somewhere, your choice, transparent row at the top, or at the bottom.

If you go over the power of two, the image will be stored in a bigger PNG file to fit the extra row.

I have issues with Background objects that are not the power of 2 as they don't behave/scale right otherwise. So I just make them power of 2 with tons of transparent areas.

The tiled image always has a row of anti-aliased pixels along the edge between solid and transparent edges......

During runtime your image size is a window showing a piece of that infinite tile.

...

If you go over the power of two, the image will be stored in a bigger PNG file to fit the extra row.

Thanks, good explanation! This wasn't a complaint btw folks, I just wanted to know what was going on. No point in re-doing things later to fix it if I can learn enough to do it right the first time.

I shall carry on creating assets to throw at the engine. <img src="smileys/smiley2.gif" border="0" align="middle" />

Thanks everyone for detailed explanations.

If it's intentional behaviour, then it is not so simple to use tiled images in places where the functionality of sprites is not necessary, but also tiling is not required.

So far I assumed that choosing TI over Sprite results in better memory usage. But, if I have to keep two copies of images - one with a transparent bottom row, and one without, this stops being practical.

Maybe Ashley could consider adding an option to the TI property sheet, to turn top/bottom row of pixels into transparency?

Thanks,

Greg

Sounds like a good solution, it would have to be the bottom row I think as my images shown are transparent on the top half anyway.

Ashley did add a way to put a row of transparent pixels all the way around the image. Hit crop in the editor with nothing selected.

However it adds the row of pixels to the size.

Edit: Actually I believe Ashley already has requests for selecting the origin point of the tile, which would allow you to move it up a pixel.

I always liked that idea because infinite scrolling backgrounds would be easy if you just cycled that number.