Seams and Node WebKit

Does anyone know why when my game runs on chrome has zero seams and when i export it through node webkit literally every tile has a seam?

doesn't node use chrome ?

Any information would be greatly appreciated.

Are you previewing in chrome or exporting?

Are you resizing your playable area in non-integers? (Windowsize for node)

Are you using pixel rounding?

Usually upon export since it's a cut image from the spritesheet/tile it has the common issue of grabbing a few subpixels of the transparency around the sprite/tile. Professional games experience this too in their engines and bleed the texture a few pixels outside of the area they're cutting.

With C2 the best way to avoid that without editing the output compiled image file is to resize based on integer, use pixel rounding, or LQ Render

Thndr

thank you for your tips!

when i am previewing in chrome everything is perfect.i had to go from the tilemap feature in c2 to the old fashioned way of one sprite with the rest of the tilemaps as animation frames to achieve this.

and after a couple of months of only previewing when i exported it with node for the first time i saw the hated seams again!ohh the irony! :p

everything is designed to be 128x128.

i cannot use pixel rounding due to the fact that i use spriter for my animations and spriter tweens sub-pixel.

if i set it to on the animations become jerky.

LQ Render: i will try it when i get home but i do not know how it will affect the image quality since everything is made for 1080p.

what do you mean to re-size by integer?(i do not use "point" since most Png's losses a lot of picture clarity)

if my tiles are 128x128 you suggest to make them smaller within the c2 image editor? like 127x127?

Point sampling fixes it, but brings a host of other problems. it's really only suitable for pixel art applications.

Pixel rounding does not fix it.

—

pixel rounding not only does not fix the problem ,but it causes shutter in movement as well!

Roccinio yup.

Just to give a bit of input that makes me fearful to use Tiled Backgrounds in a Linear sampled game:

Here's 2 screenshots of a test application ran in Chrome.

The scale is set to Crop and the image is perfectly 64x64 (The blank square is tiled background, the one labelled 'sprite' are sprites lol).

The tiled image is stretched out and used as it should be, whilst the Sprites are positioned next to eachother (64 pixels apart).

The image is totally red, but there's 1pixel line at the bottom of the image of Blue, and the top of the image is 1 pixel transparent. (Again, still keeping to 64x64, as we are advised to do this to prevent seams)

So from this setup, the seams you would expect to look the same for both the sprite, and tiled background. And it does when the zoom of the layout isn't changed. This is good!

But if you zoom out/in, certain zoom amounts will cause seams in the tiled background (Which should not happen as long as your image is a power of 2 [64x64])

This shows that it is probably better to use Sprite if your game has zooming or uses a "Project scale" feature that causes images to zoom in/out.

Ofcourse, I'm not suggesting you SHOULD use sprite, because perhaps this is an unreported bug, but I've never really thought to report it as I read from other posts that seams are a global texture/hardware problem and so it's probably going to remain this way unless we work around it.

Here is the example file I made: https://dl.dropboxusercontent.com/u/776 ... 64x64.capx

EDIT: Grammarz

I'm not sure you supposed to use 1 pixel transparent border in TiledBG's, because that contradicts the purpose of tiling in "Tiled" backgrounds.

Never had any issues with seems (except of - wonderful but useless for any not-pixel-retro project (which is a big shame) - Tilemap) and I'm always using 1 pixel transparent border only in sprites and only if they are going to rotate.

And I would suggest to not use scaling that is different then 0.25, 0.5, 0.75, 1, 1.25, 2.5 etc. cause this will always shows some artifacts and in overall will look bad

That's why long time ago (on 2nd September 2011 to be precise ) I've "attacked", but very nicely Ashley about zoom in layout editor itself - using ctrl+mouse wheel gives you strange values like 91%, 83%, 67% which makes objects looks bad and hard to position in many cases. Also I've asked about point sampling in layout editor, which was gladly added in r55 but then it was removed some time later... try to position 8x8 pixel size objects on 800% zoom hehe.

Jase00 , the seam you are describing in the tiled background is actually bleeding or lets call it blur of the next pixels (blue line), in normal instances you wouldn't stop the background at that point (1pixel away from a clear difference). A seam would be when there was a constant line between the place the texture repeats, tiled background is seamless, in point and linear, because, well in short it loops the pixels.

At export, sprites get packed together on one texture, if sprites would be packed together pixel by pixel, they would actually blur in eachother if they move in subpixels (like zooming) this is the reason why there is a 1px transparent line between sprites on the exported texture.

but here comes the real issue, if you use sprite as tiles, notice that the positioning on preview is perfect, (sprites are not packed on preview)

then on export the 1 pixel space is added to the texture, on subpixel placement you see a line between your tiles, this is the 1pixel that is blurring in each of the sides of the sprite/tile, actually its the same thing as what you showed with the blue line, except the blue line is transparent in this case, and its noticeable because the sprites are adjacent.

As for solutions, it would probably be options/different settings for exported textures or adjustments in the tilemap object, like some dedicated software for packing textures provide, or even a plugin that enables a custom texture atlas

very interesting read,

by using one of the above suggestions i set my margins to 127.5 x 127.5 (my sprite "tiles" are 128x128) and the seams are gone !

i guess the fact that they overlap by a total of 1 pixel made them disappear.

i had to remake some collision detection especially on slopes to compensate for the overlapping but everything went silky smooth.

now for the tricky part.

does anyone know why when i import my tilemap sheet through the tilemap plugin in C2 and divide it by 128x128 i can see in some places extremely thin lines around the invisible square?

they are perfectly aligned , when i cut them in photoshop and import them as sprites they have no such "artifacts".

does anyone know how the tilemap plugin handles the "cutting" of the tilemap sheet?

of course when i use sampling to "point" the lines disappear but so does my picture quality and everything flickers like a mofo! lol

Any info on this matter would be greatly appreciated.

And another question now that i am on fire!

although i have read a lot about it i am not sure about the conclusion.

right now i have 2900 objects on my first level.

90% are the same 53 sprite "tiles" .i have one sprite and 52 animation Png's for it.

65% of these have their collision detection to "off"

do i have inferior performance with this setup than if i had used the tilemap plugin with the same 53 tiles?

because if not then i would be happy to stay with my current sprite "tiles" setup.

it is more time consuming but it works for now.

otherwise i will have to figure out a solution with your help on how to get rid of the lines and the seams using the tilemap plugin.

thanks in advance.

in

do i have inferior performance with this setup than if i had used the tilemap plugin with the same 53 tiles?

Yeah for sure there is going to be performance impact, but depending on your layout size, it may vary in strength. Even that you can make C2 export this animation as one tiled image. Because TIleset object redraws those tiles as tiled backgrounds, so if you have number tiles of the same tile, next to each other in a square, it will convert all of that in to one tiled bg.