Object's Y detection failure

0 favourites
  • 15 posts
From the Asset Store
Detects any kind of ad blocker. Very easy implementation into already existing projects
  • Problem Description

    Does not properly detects an object's Y.

    Attach a Capx

    https://db.tt/K5m2C91E

    Description of Capx

    It's a scrolling game. There are 4 colors tiles randomly generated from 4 instances of a spawner.

    I needed a trigger for the spawners to generate the tiles. So i choosed: when the blue tile's Y=768 then generate 4 tiles on the spawner's position.

    I used 192/256 grid snapping.

    There is a variable controlling the speed of the tiles. The default is 8 pixels per tick so it works because 8 is a multiple of 768. The tile jumps per 8 pixels every tick.

    But the problem comes when I set speed to 9 and Y trigger to 774 (because 9 is a multiple of 774)

    It does not spawn the tiles. I think Construct 2 is not detecting collision between the blue tile and the 774 Y.

    NB: Check here for the different multiples http://www.calculatorsoup.com/calculato ... tiples.php

    Steps to Reproduce Bug

      Open the CapX Run to see how it works Now change the global variable "Speed" to 9 And change the Y detection to 774

    Observed Result

    Tiles don't spawn.

    Expected Result

    Tiles should spawn. This is the big problem, for seemless spawning i will just offset their spawn with imagepoints.

    Affected Browsers

      All of them

    Operating System and Service Pack

    Windows 7

    Construct 2 Version ID

    r 171

  • I did not look at your capx. but, why don't you create a line with an invisible sprite. Just draw it out. Set the sprite at Y 768. Use on collision with the sprite to trigger spawning. Doesn't matter what speed tile is moving.

  • Because the collision is imperfect. I've already tried this. Only the exact Y is perfect. It must be pixel precise.

  • You're spawning the objects at -256 though, not 0. 774 + 256 isn't a multiple of 9.

  • -_- true.. I will test this out with the new values and will return to say if the problem is fixed or not.

  • Sorry it does not work <img src="{SMILIES_PATH}/icon_e_sad.gif" alt=":(" title="Sad">

    I've choosen 770 value for Y because 770+256=1026 and it's a multiple of 9.

    Some strange stuff though.

    first

    The Y seems to be detected sometimes sometimes nope. The tiles don't spawn seamlessly.

    second

    And because 770 has 2 pixels offset with 768 which corresponds to the grid snapping I've put the spawn image point y+2 to compensate the 2 pixels difference. Well when I do this it does not spawn at all. Wtf?

    Here is the updated capx with the bug by the way https://db.tt/wPB88NMW

  • up

  • Try instead of doing a check for "Y = 744", doing two checks for the grid positions after and before (so if Y > 744-gridsize, and Y < 744+gridsize).

    Even though it snaps to grid visibly, maybe it isn't doing a pixel-perfect snap each tick (Also, a tick isn't guaranteed to be exactly 60x a second, but I'm not sure how that affects the grid snapping)

  • It's not the problem.

    The problem is Construct 2 is not precise enough.

    I still have gaps between tiles

  • Ashley

    We can close this topic.

    I realize I can't ask C2 to be pixel perfect.

    The problem came from a delay between spawning the sprite and actually moving it. I accepted the fact that C2 can't handly such quick operations milliseconds perfect so I've come up with alternative solutions.

    For those who might want to know. I just precreate 3 ranks of tiles and each time that for instance 3 blue collide with the sprite trigger i put those 3 new sprites in movement and immediately create 3 other sprites outside the layout ready to move.

    For moving C2 does it very well.

  • The problem has nothing to do with C2 being unable to be pixel perfect. The problem is incorrect math. You're doing the calculations for only one of them and expecting them all to work. You placed all initial tiles at y positions -256, 0, 256, and 512 in the first example and -256, 0, and 256 in the second. By adding 8 to the y position each tick you will always get the y at 768. But the space between each tile, 256 pixels, is not divisible by 9, so the ones not at y=0 or wherever you are calculating from end up missing.

    Do the math, watch the y position in the debugger or just repeatedly add 9 to 512 and watch what happens. It misses 774 and 770. It's not about either of those being divisible by 9, the problem is you're not starting from the same y position for all of the tiles, so they're offset. That's why one row works, and the others don't.

    What you need is a different method. For example, you can check is the spawners are not overlapping any tiles, and if so, get the y position of the highest tile, then create a new row of tiles at that position-256.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • The problem has nothing to do with C2 being unable to be pixel perfect. The problem is incorrect math. You're doing the calculations for only one of them and expecting them all to work. You placed all initial tiles at y positions -256, 0, 256, and 512 in the first example and -256, 0, and 256 in the second. By adding 8 to the y position each tick you will always get the y at 768. But the space between each tile, 256 pixels, is not divisible by 9, so the ones not at y=0 or wherever you are calculating from end up missing.

    Do the math, watch the y position in the debugger or just repeatedly add 9 to 512 and watch what happens. It misses 774 and 770. It's not about either of those being divisible by 9, the problem is you're not starting from the same y position for all of the tiles, so they're offset. That's why one row works, and the others don't.

    What you need is a different method. For example, you can check is the spawners are not overlapping any tiles, and if so, get the y position of the highest tile, then create a new row of tiles at that position-256.

    Thanks I will try your stuff.

    I was using a sprite trigger now though and have got the same gaps.

  • Closing as not a bug. See 'Expecting math calculations to be exact' under Common mis-used events and gotchas. The errors occur at the CPU hardware level and affect all software on your computer, not just Construct 2.

    The problem probably stems from the 'Move at angle' action, which calculates cos(angle) and sin(angle), which are often slightly imprecise. Even so the correct solution is to compare within a small range instead of expecting exact results. In fact your example does not use delta-time so is framerate dependent; even better is to use dt and a one-off action once it goes below a threshold.

  • Ashley

    We can close this topic.

    I realize I can't ask C2 to be pixel perfect.

    The problem came from a delay between spawning the sprite and actually moving it. I accepted the fact that C2 can't handly such quick operations milliseconds perfect so I've come up with alternative solutions.

    For those who might want to know. I just precreate 3 ranks of tiles and each time that for instance 3 blue collide with the sprite trigger i put those 3 new sprites in movement and immediately create 3 other sprites outside the layout ready to move.

    For moving C2 does it very well.

    hi

    i see your description but i dont understand it well

    can you send us .capx example ?

    thanks

  • hi

    can you post an .capx example to see how you solve this problem ?

    thanks

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)