vtrix's Forum Posts

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • Yann

    i'm having trouble deleting an index of array

    delete root@"array","0" or 0 both just set the arrayvalue to null

    the path "key" however is gone, but the size is still counting the null as an entry

    edit: i think i gonna use strictly object from now on and use only c2 arrays for listing things

  • frozze , heh its pretty old demo, domain is gone, but still have it, ill see if i can get it up again

  • Yann , first impression, looks great, love the debugger and log info, and the new way of displaying with "@" feels a bit lighter,

    but just wanted to quickly say, that something as loopindex is missing, and could be usefull for not making a counter, or what i just did,

    for an array int(json.currentkey) , is that a design decision?

  • yes, indeed at runtime, one texture was what i had in mind, so it would combine about 30+ sprites in one texture

    still getting my head around, converting the same tiletechnique to one texture,would i need to redraw the full texture or only a part?

    thanks for the answer, i need to invest some time in the idea...

  • rojohound , something that i was meaning to ask about canvas use

    using sprites for tiles..

    and using the process of switch tileframe from arrayposition (create and show only tiles in view)

    could the same process be used/combined with canvas. actually making a looping texture from tilespasting

    for seamissues, is it possible to paste relative to canvasorigin, so the texture is composed of non floats

    (seams in floats are actually the main issue here)

    would this be is it a realistic aproach, performance, technical? any insights?

  • Yann , damn, just when i wanted to get some sleep, i see this.. great! who needs sleep! testing....