help! I can't get collisions to work properly!

hey guys I'm new with construct, and I'm having troube with collisions. Not an exception, but a rule: collision is being undetected VERY OFTEN.

And my images are not pixel art stuff, my games are usually 80 or 60 fps (no slowdown or skipping).

since I couldn't find any other topic/bug report about this issue, I wonder if it's a compatibility issue.

however, I think it's written in c++, isn't it? I never tought a c++ code would have compatibility bugs

My pc is a intel dual core, pentium XP, nvidia card etc, nothing so special or rare to find about compatibility or whatever.

I'm posting here because that's not just a bug, that's a major problem that bugs me A LOT, and makes it impossible for me to make any games. I also reported the bug on the tracker, of course. And there's a cap at the tracker, that I'd like you guys to test if the collision is really only on my pc.

the report:

http://sourceforge.net/tracker/index.ph ... _id=207820

the cap for download: http://sourceforge.net/tracker/download ... id=2298967

(Keep pressing the right arrow. One time or another the sprite should fly out of the loop)

and, btw, YES, it really can stay STILL on top of another sprite (with collision all set) without detecting collisions, so it has nothing to deal with fps, it's more likely that the collision turns off at times

edit> every image I try to upload is labeled as an attack vector, so I don't have any avatar to show. sorry.

I don't see anything wrong with collision detection mechanysm in Construct. In this posted CAP this movement is so fast it can make this blue dude go inside the black black bar. And once he gets into overlapping it, there's no way any collision with new instance of black bar can be handled.

Try setting framerate to "Unlimited" from Application's properties and you'll see that when FPS are much higher then movement per frame is not that fast.

This problem is similar to this one:

http://apps.sourceforge.net/mediawiki/construct/index.php?title=Time_Delta#Drawbacks

[quote:2icjnmxq]

edit> every image I try to upload is labeled as an attack vector, so I don't have any avatar to show. sorry.

You have to use a .JPEG or .GIF I dont know why but you cant use .PNG...

It actually looks like a bug, I seem to be able to get false positives for 'Is overlapping' in that .cap as well. Ergh. When we have time we'll get round to fixing it (thanks for putting on tracker).

I don't think it's a bug, and I'm pretty sure I've figured out what's happening.

Likewise, it's not the speed, I slowed it down to 200px and it will still do it. It just does it faster when it's fast.

Here's what's happening:

On Collision only registers once when objects overlap. If they continue to overlap, they will register nothing for On Collision after the first tick of overlap.

Your sprites are all Per Pixel collision. On Collision only triggers when the very front corner of Mega Man's shoulder touches the black portion of your barrier. Then the angle flips.

Sometimes the Mega Man sprite can be in a position where it will trigger an On Collision with a barrier and flip... but flipping triggers On Collision with the back corner of Mega Man on the barrier behind him, so he flips again.

Since he's triggered On Collision in the previous tick with the first barrier, it will no longer trigger because Mega Man has moved into the barrier by then.

So in other words, it's a flaw with your design... not with Construct. You need to make a more refined design that will do what you expect it to.

I've also tried other forms of collision so it would change... see: I've tried overlapping, on collision... and even both. oh wait, I've tried even collision with solid (setting both sprites as solid, of course) and I couldn't even get the first collision in that case.

I've got to the extreme of trying platform behavior without gravity, speed etc to get the solid collision.

But in the end, megaman (wich is a random sprite I've picked just to figure how to make a loop) always ended up going out of the loop in a different way. yes, even with overlapping, wich made him go out on the funniest way possible:

overlapping with the loop slowly until he finnaly loses contact with it and fly away.

and about the angle issue pointed by deadeye: I've noted it even before I posted, because I did all I could to get outta the problem, but, as mentioned above, overlapping also takes him out, and I can clearly see that the first wall he touches is mostly the right one, since he usually's NOT touching the "ground", and he goes out even when he touches the right wall only.

(by "right" I don't mean direction, I mean the wall he must touch to change direction)

so, I got your point deadeye, since I suspected about it too. and I still suspect a bit, since I've separated the bars and left only 4 of them, and he moved like a square, and worked well.

but, for the reasons mentioned before, I'm afraid it isn't the case.

edit: maybe I should upload a pic. should I make an account in photobucket or stuff like that, or is there another way?

I am certain it is a bug. I modified the .cap to make it move slowly and used a text object to display when it was overlapping a barrier. It clearly was registering an overlap when the objects were not touching. Since 'On collision' basically checks for an overlap with a built-in 'Trigger once', these false-positives would intefere with the On Collision triggering. So I'll try and sort out something for the next build...

Maybe it is after all then. I'll defer to your expert analysis

This is fixed in the next build. Many thanks for the bug report - it turned out to be a very subtle rounding error that caused out of bounds memory access. This meant false positives on collision tests, and also possibly even crashing. I was suspicious something was wrong in collision testing (I'd had problems before), and this bug report helped me track it down. Thanks

there must still be bugs in collision (at least when objects are using the "path" behavior. during testing, objects frequently stop multiple widths away from objects they have collided with.

rpmcnee

there must still be bugs in collision (at least when objects are using the "path" behavior. during testing, objects frequently stop multiple widths away from objects they have collided with.

You have posted this in the retired Construct Classic section.

Is this what you intended?