Gaps with scaled tiles in browser but not preview.

Hi guys,

I have created a layer where i have some 64x64 pixels tiles in a grid formation. Then I change the scale of the layer depending on the players actions. However, I seem to find a difference between previewing and viewing the exported files in browser.

When I am previewing in Chrome there are no gaps.

When I export the project as HTML5 and view in chrome I get gaps.

So why is the preview different from the browser?

Kind regards,

Wyrm

Just to note before I get posts suggesting I should change project settings, I already have a solution that gets around this issue. What I am interested in is if it is a bug, since the preview in chrome is perfectly capable of scaling without gaps.

Day 2 - Bump

I don't see any gaps. Upload a capx.

Also, you posted this in the General section of the forum. If you need help I suggest you post in the Help Section next time. There is a far more active community over there.

Tekniko I don't need to upload a capx. The gaps are clear. Try using something other than a mobile phone or a very high resolution monitor to view those 64x64 pixel textures (or just zoom in)

Also I don't need help. As I clearly stated in my follow up post I have my own game specific solution but I want to know the difference between viewing via preview and viewing the export in browser to identify if this is actually a bug. As it seems to me if there is a difference then there could be an exporting problem. Which I think is appropriate for the general section.

Ashley bug or not? If not what is the explanation for the difference?

Upload a .capx

Ashley If it was that easy then I would have done it in the original post, but I can't because I don't want to share my source to the public. It will take me some time to prepare an example capx, so in the meantime I will pm you with a link to my game.

OK, I can't PM you since it's disabled for you.

I report stuff like this for the benefit of Scirra and the community. I don't have time to find the exact set of conditions that cause this problem right now, and personally don't need it fixed for what I'm doing at the moment. When I do I'll post an update.

OK, I can't PM you since it's disabled for you.

I report stuff like this for the benefit of Scirra and the community. I don't have time to find the exact set of conditions that cause this problem right now, and personally don't need it fixed for what I'm doing at the moment. When I do I'll post an update.

Thank you for your detailed bug report. The Scirra community thanks you whole heartedly. Unfortunately you didn't post this in the Bug Forum or even bother to use the Bug Report Template. I don't know, maybe this is the Bug Report Forum and your original post wasn't actually a question. I am, after all, on a mobile device and or high resolution monitor so I can't see anything.

Tekniko Not sure if you're capable of reading? If you were you would know that I don't know if it's a bug or if there is logical explanation. Hence, why I am asking in the general section to scope out if others have had a similar problem, before wasting Scirra bug investigation time. I don't need your kind of help since all you seem to be trying to be condescending. So I'm afraid you're are just noise.

If you missed it the question was followed up by a question mark.

[quote:28xy62wd]So why is the preview different from the browser?

You have not given any kind of information if there should or shouldn't be a difference between running a game in preview in chrome against running the export in chrome.

Well, you haven't given us much to work with, but I would first try disabling "Use high-DPI display" project setting in C2 and see if that makes both operate the same.

Kind of a long shot , but I remembering it causing differences of this nature between iPad and iPhone when working with parallaxed layers and the positions of objects on those layers. Seems like scaling the layers could have a similar effect on positioning.

Again, not sure it'll even do anything given you are testing in chrome, but can't hurt to see.

Sigmag Thanks. I would have provided more but I couldnt narrow down the issue to provide a capx, while also not wanting to provide my full game capx. I went through your suggestion to no avail, but I did fix it briefly.

I thought turning pixel rounding off fixed it. However, what I did was accidentally export my build to the same directory I hold the source and upload the entire folder to my server. Opps

So I'm not sure what that suggests... perhaps it started using the original images? Therefore perhaps it's caused by using brute png compression? So I have checked my exported tile image, which is actually in a tile sheet now. This is because I use 1 frame animations to put all my differently decorated tiles of the same type into one sprite object. Then at start up I randomly choose one of the animations. Therefore dynamically decorating my scene.

So I guess the next thing to test is playing with different compression levels and perhaps using a tile sprite with no animations and therefore not in a tilesheet. However, I have run out of time today.

I will leave you with this though. My original questions has always really been. Should there be difference between previewing and viewing within the same browser? If so what things are different? What things are applied during the export apart from png compression and minifying?

P.S. It's pretty cool to know that you can kind of create spritesheets by using animations this way. However, it's a shame you can't specify the spritesheet dimensions (or can you?).

Sigmag Thanks. I would have provided more but I couldnt narrow down the issue to provide a capx, while also not wanting to provide my full game capx. I went through your suggestion to no avail, but I did fix it briefly.

I thought turning pixel rounding off fixed it. However, what I did was accidentally export my build to the same directory I hold the source and upload the entire folder to my server. Opps

So I'm not sure what that suggests... perhaps it started using the original images? Therefore perhaps it's caused by using brute png compression? So I have checked my exported tile image, which is actually in a tile sheet now. This is because I use 1 frame animations to put all my differently decorated tiles of the same type into one sprite object. Then at start up I randomly choose one of the animations. Therefore dynamically decorating my scene.

So I guess the next thing to test is playing with different compression levels and perhaps using a tile sprite with no animations and therefore not in a tilesheet. However, I have run out of time today.

I will leave you with this though. My original questions has always really been. Should there be difference between previewing and viewing within the same browser? If so what things are different? What things are applied during the export apart from png compression and minifying?

P.S. It's pretty cool to know that you can kind of create spritesheets by using animations this way. However, it's a shame you can't specify the spritesheet dimensions (or can you?).

The différence is compression, spritesheeting (!) And minification mostly, the spritesheeting can cause seams, the downscaling quality parameter changes the way itnis,spritesheeted I think

Aphrodite Thanks for that information it took a long time to get there . I can confirm that changing the downscaling from medium to high, changes spritesheet size from 256x256 to 512x512 (probably only if required). That's good to know.

So I guess in my test capx I need to also try tiling sprites that use a spritesheet. My gut instinct is this will result in the glitch I observed, as it seems like a logical explanation.

I'll be back!

Sounds like my issue was solved in the recent beta. Woop!

"When building spritesheets on export, Construct 2 has typically inserted a 1px transparent border around each image. This avoids color from an adjacent image on the spritesheet "bleeding" in and causing a fringe of a different color to appear down the edge. However this actually caused a different problem: in preview mode images work in a "clamp-to-edge" mode, meaning they show the last pixel's color right up to the very edge of the image. (Visually this looks like "hard" edges.) After export, since the edge of the image is now against transparency, it then means the last pixel's color actually blends with transparency up to the edge. (Visually this looks like "soft" edges.) In short, this means in some cases seams can appear between adjacent objects after export, because the edges are now blending with transparency at the edges, allowing some of the background to show through in between.

To resolve this Construct 2 now repeats the outside row of pixels from the image instead of inserting transparency around frames. This ensures that after export images blend at their edges the same way they do in preview mode, and helping prevent seams appearing. If 'Downscaling' is set to 'High quality' images are (as usual) padded out to power-of-two sizes for correct rendering with mipmaps, and now C2 also fills the entire padded area with the last row of pixels. This might look a little odd on your spritesheets, but it guarantees seamless rendering even with extreme downscaling."

~https://www.scirra.com/construct2/releases/r185