Object's Y detection failure

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.

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