Found solution for seams

vtrix

if you do screenshoot, then zoom to vertical | line between color segments. But for me it is almost perfect

vtrix No black seams, just blurry edges where the tiles look like they are bleeding together. I'll try to grab a screen shot.

It's much better then the before result, no doubt about it, but you can see there is some bleed through around the tiles which causes a blurry look. I opened the screenshot in gimp and zoomed in on the corners of the tiles to make it easier to see. Of course it probably would be less obvious using the real tiles rather then the high contrast ones.

<img src="http://www.dennisburch.info/1.png" border="0" />

<img src="http://www.dennisburch.info/2.png" border="0" />

<img src="http://www.dennisburch.info/3.png" border="0" />

My system info:

Windows 8.1, Intel Core i7-4800MQ 2.70GHz Quad Core, 8 Logical Processors. NVIDIA GeForce GT 740M. Updated drivers. Screen Resolution 1600x900. Previewed in Chrome and Firefox.

yes but 0 seams, and as long as its only a 1px blur on each, it would be invisible, because of the tiling, good example is the single color-tiles, i probably do another test later with different tiles

Another thing to remember is to use a good blending color behind the tiles, so that when it does show through it isn't as noticeable.

Design you background graphic with mid-range tones, not to bright or dark. or have the sky fade darker and less saturated down near the majority of ground.

Watch your game, see where the seams show the least, and do whatever works there more often.

Ashley

what happens to people that use spriter for their animations?

if you use pixel rounding to "on" you fix the seams problem but scml files become weird and jerky since it tweens sub pixel.

are you aware of this problem?

Yes, and there is nothing specific to Construct 2 here, it's a normal result in computer graphics. You have a tradeoff between smooth rendering with seam issues to pixel-rounded without seams.

Ashley

maybe i haven't phrased my question correctly because that was not the answer i was expecting.let me try to be a little more clear.and what i am about to say comes from my heart with the best intentions.

after some months using construct i have come to the conclusion that there is no specific company strategy on where you want to go with your product.

what i mean is that you add tremendous features at a rapid pace but without thinking the consequences in the long run .

you added tilemap support .i had to dig into the forums to learn everything about seams and sub pixel rendering after spending some time scratching my head if i am incompetent in creating correct tilemap sets .i had no warning about that anywhere for a manual post to a blog post.

we have spriter. i believe that you are involved as well in the plugin development.i spend a lot of time to create animations that i will soon reveal and i believe they are top notch only to learn that is either this or that.

see where i am going?

you have to pick what things are the most important make them work 1000% and then move on to something else without promising the world and in the end of the day you leave behind heartbroken customers.

i will talk specifically about spriter since i firmly believe is a game changer for both of you , as i will try to explain .

the animation quality ,the fact that it only needs one set of png's for a thousand animations and the easiness to import to c2 makes it an invaluable ally to create games that stand out.

work together ,bundle your two software's as one (or with an exclusive plugin like wii u at an added price ) make it work 100% with all features like tilemaps and advertise it as a complete solution.

i had no warning about these conflicting situations.

right now many customers are under the impression that c2 works with everything (if it a marketing plan then kudos to you) fom cocconjs, to crosswalk, to spriter to node webkit etc etc and this is partially true. it works until you start reading the hundreds of post trying to find a viable solution to their problem.

i am not saying that you are responsible for 3rd party support but right now they create more problems than they solve .

soon you'll be ready to implement multiplayer. will it work with mobile? with steam? with crosswalk? with wii-u?

if yes , will ludei support it? maybe intelrobert? or it will only work on browsers?

i kinda know the answer since i have read your posts and my question is , is it worth your time developing it or you should spend that time in securing partnerships with other software developers or writing your own mobile exporter so later on since you have full control over it, add mulltiplayer ?.

i am grateful that you gave me the opportunity to create games , but the deeper i get into game development and the bigger the project becomes the more frustrations i encounter not regarding designing my game which i expected day one to be difficult but from behind the scenes tech that does not work as promised .

Roccinio - I have no idea what to tell you. The seams issue is a normal result in computer graphics and I'm not currently aware of any convenient workaround. Some engines don't even support sub-pixel positioning, so at least you can do that if you want in Construct 2, although it can have side-effects.

I think a question that hasn't been fully answered is the difference between preview and export - There are quite a few rendering differences between preview and export I'm not sure how to fix. These include seams, weird 1-pixel wide extensions from the edges of tiles, stretched gradients rendering differently, etc. Clearly something's causing this...

sqiddster

thank you buddy!

that is a perfect example why i am ranting ,

tiny little things that are left behind for every new thing that is added to c2 that eventually add up and starts to cause unexpected trouble when you least expect it.

Ashley - couldn't this whole problem be solved by making tiles overlap by 2 pixels, or a user adjustable amount?

Arima - that would undo the optimisation that handles entire rectangles of tiles at once, and degrade performance. Imagine a 2x8 tile section with only four tiles down one side. Either you extend by 1px, cover up the seam, and then the unexposed part is rendered too far over, or you don't extend and there's a seam.

i thought about this problem, and its really bugging me, because ...

1. i want to use linear, it too nice to not use it

2. its perfect on preview

3. other programs use it

4. i want to use construct

consider this linear example

a 16 at 16 tilemap, about 76 frames

sprite tilemap imported from tiled (no plugins needed) hold mouse to move, mousewheel to zoom, starts at zoom 2

download and preview file / perfect no seams no bleeding, even when scaling / construct can

https://dl.dropboxusercontent.com/u/61666915/tilemaptest.capx

on export this happens, the actual background is showing thru = seams, ( no bleeding tho ) / construct can't

https://dl.dropboxusercontent.com/u/61666915/tilemaptestv2/index.html

so as showed in my early version with the colors (modified export), its possible to have tiles perfectly aligned and no seams, so this means, whatever happens it is happening internally on the texturemap and not on the positioning of the tiles

ps: what you will have and always have is a little bit of blur from the surounding color but this is not an issue and almost not noticeable (well check the preview)

so its pretty clear to me that construct engine can display linear perfect, so its really a question what happens on export

for the bleeding there's the 1 pixel transparent gap, not actually a problem, but it needs adjustments, it must consider transparent space for two tiles and a setting for these transparent pixels

libgdx has its own texturepacker, there are the follow options, and i think the bleed one is actually another name for what extruding actually is

these are there standard settings:

paddingX The number of pixels between packed images on the x-axis. 2

paddingY The number of pixels between packed images on the y-axis. 2

bleed If true, RGB values for transparent pixels are set based on the RGB values of the nearest non-transparent pixels. This prevents filtering artifacts when RGB values are sampled for transparent pixels. true

edgePadding If true, half of the paddingX and paddingY will be used around the edges of the packed texture.

link: https://code.google.com/p/libgdx/wiki/TexturePacker

this makes sense, because linear will pick the surrounding pixels of the texture actually the subtexture, to make transition, and now the two tiles takes the transparent pixels of the 1px gap, that is why we see this obvious border around the tiles on export.

theres also an analogy between 3d models used in games, always padding between uv's and never stop your texture on the uv-border or you get the same black lines on your model

now for the c2 tilemap, if it would use the same texture method, it could still use the optimization, because again, the texture size is not changed, and there is no overlap.

so i hope you consider testing these settings out, i don't know if this is a convenient workaround, or easy coded, but its definitly worth trying something other engines are putting in and something where most of us are having trouble with, especially when you consider that on preview you could asume that everything is working fine...