Coin-coin le Canapin's Forum Posts

  • That's quite interesting. Can you attach the two capx ?

    About my project, I'm now trying to stick to tilemaps (and arrays to store additionnal informations for each tile) rather than spawning some blocks. I'm not sure yet which method I'll use.

    If I use some sprites only for destroyed blocks (just to set a timer behavior and maybe one or two variables), I'll have I think 100; 200 or 300 sprites at the same time instead of 4000 so it could be fast enough.

    Storing my data (including my timers for each destroyed tile) into an array would, I think, give better performances, thought it's more complicated to handle with events.

    I'll try to do some tests with both methods.

  • I managed to achieve what I wanted : http://canapin.com/construct/tolilo/07/

    I noticed the game slows down when there are many projectiles on the screen.

    My guess is that the event "projectile on collision with block" (where block is a sprite) iterates over all the block sprites, which are still about 4000. So, if there are 10 projectiles on screen, it iterates over 10*4000 tiles on a tick. Is that right ?

    So I guess I'll going back to tiles and find a way to manage stuff like timer regeneration for reach tile.

  • It's also an indian flat bread.

  • Hi !

    Thank you for your advices <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    I was well aware of this issue and I rewrote my engine using tiles only. It was way faster but it made the blocks regeneration difficult. I tried to store their timer in an array but it was kind of glitchy.

    So I tried another way, by keeping using blocks but storing them in an array as using sprites provided me more flexibility.

    It's quite effective : http://canapin.com/construct/tolilo/07/

    I also made new block frames so my map is more "precise".

    The issue I'm facing now is that when there are a lot of projectiles on the screen, it starts to slow down when looking for collisions with blocks.

    My guess is that because on the "projectile collision with block" event, it iterates over all the blocks. If there are 10 projectiles on the screen, it iterates over 10*4000 blocks.

    I have two ideas.

    1) Instead of looking on collisions with blocks, I could compare the projectile with block coordinates in my array. But that would be kind of complex, especially with blocks which don't have a square hitbox. Plus, I would like to put a behavior physic on blocks (not movables) and projectiles, and I'm pretty sure it will have terrible performances.

    2) Going back to tiles and try to :

    a) make my array containing timer work

    b) using invisible sprites containing a timer for each destroyed tile all over the holes created, and remove these sprites when the timer ends

    And hoping that the physic behavior will work smoothly when using tiles instead of blocks.

    If you have an advice regarding these solutions, I'm interested in. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • "system -> start of layout" is the condition.

    The full action "path" is : "system -> global & local variables -> set value -> timer : 0"

  • Is it useful to set "time" to integer ? Isn't it already an integer ?

    By the way, you just have to do :

    system | start of layout -> set timer to 0.

  • My question was more in a general way about how to efficiently pick some objects among a lot of instances and the array thing seems to suit me well.

    That said, this is what I want to achieve :

    I have a level made by from lot of violet squares as sprites.

    When we click somewhere, it destroys some blocks in a given radius (a slope is just a different frame from the same sprite) :

    [attachment=2:zlaz61oa]hole1.png[/attachment:zlaz61oa]

    I want my hole to have slopes on each "corners" :

    [attachment=1:zlaz61oa]hole2.png[/attachment:zlaz61oa]

    And this for any given radius or shape. A bigger hole would make this (I did it manually) :

    [attachment=0:zlaz61oa]bighole.png[/attachment:zlaz61oa]

    Plus, when a player creates a hole, the hole regenerates hitself somewhat square by square :

    You can try it here : http://canapin.com/construct/tolilo/06/ (arrow keys, left click)

    For each square regenerated, it needs to scan surrounding blocks to know which frame must be set at the current square (frame 0 : full square, frame 1 : top left slope, frame 2 : top right slope etc…).

  • If the only way to pick a sprite without iterating over all the other sprites is pick by UID, how do you return a sprite instance given this XY coordinates without storing its data in an array ?

  • nimos100 : thank you for this in-depth explanation

    mattb : As you speak about it, it's exactly what I tried after Rojo's last reply . It took some time because my events are a mess and I wanted to know if there was an obvious reply to my question before spending two or three hours (I need at least that, I always get lost in the X and Y kingdom…) to try it.

    That said, it seems to work so far.

    Here a partial screenshot of my last nested function (the part that caused my computer to stop for ¼ second) :

    [attachment=0:w5uxjhr4][/attachment:w5uxjhr4]

    Laggy : System | Pick block by evaluating block.X = x*size & block.Y = y*size

    Instant : Block | Pick instance with UID grid.At(x,y)

    Hooray !

  • Source-in ?

  • Ah ! This is indeed good to know.

    So If I understand well your message I can do something like this :

    Create a two dimensional array with a width about 100 and a height about 60, then I fill this array with my block X and Y coordinates and I set the block UID at this index.

    Then I can do : block pick by UID = (array.at(someX,someY)) ?

    And that would work with the expected performances ?

  • edit : nah, I made a mistake

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thank you for your explanation . I guess there is no way to store or organize sprites the same way to get them faster ?

  • Hi.

    In had a project with about 4000 sprites named "block". They were spawned automatically with events.

    I had multiple nested loops with "pick by comparison" or "pick by evaluate" on "blocks"

    Like :

    pick blocks by…

    foreach block

    -> function "search"

    function search : "pick blocks by evaluate"

    On my first loop : no problem

    Second nested loop : no problem

    Third and last nested loop : micro-freeze during this loop, which was just a simple "pick by comparison".

    So I thought one tick was not enough to do something like : search for theses blocks inside 4000 blocks. Among these found blocks, for each of them, test for surrounding blocks inside 4000 blocks… etc.

    So I guess it was pretty normal if it was kinda slow.

    However, I modified my events to replace my blocks by tiles from a tileset object (same number of tiles as blocks : about 4000).

    It appeared that nested loops to search specific tiles was a lot faster.

    I discussed it with a programmer friend. I have some basic programming knowledge but he's more skilled than me so I listened to him .

    Basically, he said that picking some objects by an evaluation or comparison among a lot of objects can be slow or fast, depending of how they are "organized" (not sure if it's the right word, my english isn't as good I'd like). If the objects are sorted in an array with for example their coordinates, well, looking for one object among 50000 other ones will be very fast.

    In Construct 2, my nested loops with sprites were slow.

    Same loops with tiles were very fast.

    So I supposed that it was because the tiles are sorted in an array, somewhat as a grid, so looking for one or more specific tiles is very fast.

    Is that right ? Could you explain the fundamental differences between tiles and sprite regarding performances and how Construct 2 gets access to them ?

    I hope my message is understandable. Hard to explain technical things with my english !

  • I did like this :

    [attachment=0:1etqwah0][/attachment:1etqwah0]

    Works well. I spent about one or two hours to figure out I used positionToTile instead of tileToPosition though.

    By the way if the global variable blockSize is equal to a tile size I could also write :

    loopindex("tileX")*blockSize

    instead of

    map.tileToPosition(loopindex("tileX"))

    and so on.

    It's a matter of preference but I don't really like to have too much parenthesis nor dots.

    I can't use tile range because I'll need to test every tile in this area later to do stuff.