RenatoB , yet another way would be to push the uid you want to check in an array, then for each x, pick uid at array.at(curx) and compare whatever

restore/maximize window browser (middle button browser)

i doesn't seem to work with browser resize trigger, any suggestion?

its for positioning elements on trigger

is this a known limitation?

so yes for fixing seams, (only for sprite tiles)

(this is from my first test, so i dont know yet what can be modified and what not)

original map i imported in c2

i added 1pixel padding around clusters (so they don't touch there borders and also not touch other clusters)

too better show the 16pixel grid and placement

import > this is in import sprite strip

notice that i only use 7*16 tiles, instead of, 8*16 tiles that would fit a 128 texture, this is because the automatic texturepacker adds a 1px transparent border around the tiles, if you use 8 it will scramble you imageclusters in different textures

(note, in this example i could have filled the 7th row with something)

after export (this is the actual map i used in tiled, again not yet totally sure if i could also use the originial

modified texture, i start at the top dragged the pixels from just above the 1px gap on top of the transparent area (you can drag a whole row over it) then did the same from left to right, (you wont notice this as instead of a transparent line it will be the same color pixel that gets blurred in)

this can be done pretty fast, the outside borders (off the full texture) i just filled in with the grass color

replace the original exported with the modified, result

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

so yes, its not the perfect workflow, but i hope this helps, and i hope there's a better workflow in the future

tgeorgemihai , your actually right, its sprites, 2600 50*50 (there's a row to many, you can clearly see how small one tile is pretty amazing it runs silky smooth on my nexus7, but because of everything is in arrays, you could optimize the count..., i dont know if i have to be sad or glad, because ive been telling this since the post where i claim to found a fix for seams. I just went testing the actual tilemap object, i thought i could potentially work like its now, but i see there are seams even on clustered objects.

finaly found a solution, sprite as tiles 16*16 tilemap, created in tiled, imported in construct, and adjusted the exported tileset

scaling is fullscreen inner, sampling linear, pixelrounding off

(if you zoom in very close, you will see some fine lines, but this is actually because of the graphics themself, >very small and also is exact the same on preview)

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

what do you think? clean enough?

tgeorgemihai , i cant do much with an image, i was refering to just the tilemap setup you currently have in a capx (no game-events needed) , so i can try some tests with the export. (but i see its not the normal seams, so i guess your using c2 tilemap and not sprites, so adjusting exported images wont work)

tgeorgemihai , this fix only works in some cases, it worked with big tiles, tiles that even when exported were adjacent to eachother, this means they matched perfectly side by side top to bottom, i just needed to remove the transparent line between them, and they matched perfect, the problem you have when importing tiles in spritesheet, they get scrambled and different kinds are adjacent to other kinds, removing the lines will only have the effect of bluring wrong colors in each other,

if you work with tilemap it is different and wont work with linear period., its one texture splitted in multiple images without padding, so linear will make them blur on each other.

if you''re using sprites as tilemap and have an example of the tilemap, positioned, ready to test and export im willing to try and make adjustments, other possible solution is in positioning and making them overlap 1px, other than that its the usual, use point... blabla

— , i know its not indicative... thats the point, there's not reason the debugger should run a heavier process "on default" compared to other modes, if every mode runs its own subpage, the performance should be more or less equel, thats why i would like to compare,

so are you saying you have same experience that inspect runs heavy on system page?

Ashley and anyone who wants to test, wanted to know if you experience the same big difference in cpu usage

Testfile

(168 stable version)

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

if i run this testfile in debugger (inspect), it shows me about 22% cpu usage, pretty heavy you would think

if i then swith to watch or profile, it runs at 0 to 2%

if i go to inspect - sprites - #0 it runs at 6% (notice there are more fields updating than on systempage)

if i go to inspect - system - its back at 22%

i still think that system overview (debugger default) is running something more then just its own page, why else so much difference?

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

Yann, yes sorry, was a bit fast on the suggestion, should wait till i get some sleep

its because i"m just using a new technique (for me), combining the use of c2 array with pathsetting of json, i drive one or more paths with a c2 arrraylist, so loop is driven by the array curX, but like you said the currentkey is is always known in the code, anyway i shut up now, i agree with ScottA ... A+ plugin, everything is working smooth and my project is shaping up...

Yann , just wanted to mention, i have some instances where i could use the json.key like it was before, json.key(1), i know it was me who suggested using currentkey, but the way its now, you cant use it outside of a loop and the key(1) option isnt there anymore,, if you set the path to current and then use currentkey it doesn't return it.

i mean, currentkey, or currentvalue, would always return the the key / value at currentpath whether you're in a loop or not, so in sense its a shortcut to key(1) or value(1), but the parameter kind should also be an option

so in the end you have currentkey, currentvalue, or key(0,"..") key(1) , value(0,"..") value(1) with parameter usage

why i suggested it, is because i think it will be easier to understand for somebody new to the plugin, you just set the currentpath, and then use the currentkey/currentvalue, for advance use you have parameter options.