Problem with collisions and bullet behavior

Umm. Its strange.. when my bullet hit the wall something it work.. something not.. depending on where the player shoot the bullet. Here what happen...

The bullet impact animation aren't aligned to the wall. Most the time it is.

My event is basically... once bullet collide create the bullet impact at x and y position of the destroyed bullet. So i expect the collisions to be pixel perfect.. which it doesn't seem to be.

Any ideas how to fix this ?

The bullet can not be guaranteed to be pixel perfect. Bullets move X pixels per tick. If that rate is 'fast', the collision will not happen at the wall edge. This has been discussed on other threads.

That what i would have expected... but there must be a trick to do it. I can't believe there none.

You could check for distance and destroy the bullet several pixels before the wall. Another option would be to set it's position on collision to several pixels back. In both cases you got to make case of bullet direction/angle.

(Pixel perfect or instant-hit bullets)

+Bullet.count > 0

+For "" from 0 to 5

-Move Bullet 60*dt in angle of Bullet

+On loop ""

+Bullet collides with solid

-Destroy bullet

(Pixel perfect or instant-hit bullets)

+Bullet.count > 0

+For "" from 0 to 5

-Move Bullet 60*dt in angle of Bullet

+On loop ""

+Bullet collides with solid

-Destroy bullet

Can I ask you why are you suing loop, and why 0 to 5?

(Pixel perfect or instant-hit bullets)

+Bullet.count > 0

+For "" from 0 to 5

-Move Bullet 60*dt in angle of Bullet

+On loop ""

+Bullet collides with solid

-Destroy bullet

Interesting. I was about to end up with a pretty complex algorithm but i decided to take a look at your snippet of code. However, like megatronx, i don't fully understand the logic behind this snippet of code.

From my understanding... you seem to use the loop for detecting if the bullet collide with the wall. Why? Plus, isn't Bullet collide a triggered event ?

-Move Bullet 60*dt in angle of Bullet [/code:1w11h5hx]

So your not using the behavior, your doing it manually. Is there a reason for this ?

Other than that... i found a way of doing it. Put a detector in front of your bullet (pixels ahead) when it hit the wall it stand still until the bullet reach the wall, during that time you can adjust the position of the detector and when the bullet hit finally the wall, destroy the detector and create the bullet impact at his location. The detector must match the same bullet trajectory for this to work. So for direct trajectory this would be easy..

I learned it in a MMF tutorial years ago. There are probably more sensible ways of doing it but whatever, it works. The idea is that even though the bullet is moving, say, 5px per tick, collisions are being checked for each pixel it moves.

I learned it in a MMF tutorial years ago. There are probably more sensible ways of doing it but whatever, it works. The idea is that even though the bullet is moving, say, 5px per tick, collisions are being checked for each pixel it moves.

OK! I get it now. Interesting.However, i sense a performance problem. You basically check even if there is not collision around. But maybe the cost is not high enough to have any impact. But if you shoot your projectile far up to 400 pixels.. you will have more than 400 loops. So firing many projectile at the same time might be costly. But thanks!

OK, here's mine.

Bullet is on screen
For each bullet
distance(bullet.X,bullet.Y,tile.X,tIle.Y) < 10 - destroy bullet.[/code:2jcwo9il]

Of course you can replace 10 with any other number that works best for your set up. 

Now I'm not sure if Bullet is on screen & For each bullet are necessary. You will have to test how it works without one or both of them. I'm using For Each often, because otherwise event applies to all instances of same type ( I'm bit confused about this since @Ashley wrote somewhere that it is working like a loop even without a loop, but from my tests it doesn't work that way, and I tend to use for each )

Another option to do is to make condition "Bullet overlapping at offset". if you set X to "-10 & 10" , and Y to "-10 & 10" too, should work ( if not try "-10  | 10"). Let me look at one of my prototypes to remind myself.

EDIT@ Right, forgot that that project files got corrupted due to crash. Oh well.

OK, here's mine.

Bullet is on screen
For each bullet
distance(bullet.X,bullet.Y,tile.X,tIle.Y) < 10 - destroy bullet.[/code:2kqznxpc]

Of course you can replace 10 with any other number that works best for your set up. 

Now I'm not sure if Bullet is on screen & For each bullet are necessary. You will have to test how it works without one or both of them. I'm using For Each often, because otherwise event applies to all instances of same type ( I'm bit confused about this since @Ashley wrote somewhere that it is working like a loop even without a loop, but from my tests it doesn't work that way, and I tend to use for each )

Another option to do is to make condition "Bullet overlapping at offset". if you set X to "-10 & 10" , and Y to "-10 & 10" too, should work ( if not try "-10  | 10"). Let me look at one of my prototypes to remind myself.

EDIT@ Right, forgot that that project files got corrupted due to crash. Oh well.

Look like a nice improved addition to the problem. I will try to implement this in my example. Thanks!

Edit: Can't use your algorithm. The reason is we do not have access to the tile data. I am using a tilemap.. there no way to know which tile we going to collide.

> OK, here's mine.

>

>

Bullet is on screen
> For each bullet
> distance(bullet.X,bullet.Y,tile.X,tIle.Y) < 10 - destroy bullet.[/code:nxgp0o3b]
> 
> Of course you can replace 10 with any other number that works best for your set up. 
> 
> Now I'm not sure if Bullet is on screen & For each bullet are necessary. You will have to test how it works without one or both of them. I'm using For Each often, because otherwise event applies to all instances of same type ( I'm bit confused about this since @Ashley wrote somewhere that it is working like a loop even without a loop, but from my tests it doesn't work that way, and I tend to use for each )
> 
> Another option to do is to make condition "Bullet overlapping at offset". if you set X to "-10 & 10" , and Y to "-10 & 10" too, should work ( if not try "-10  | 10"). Let me look at one of my prototypes to remind myself.
> 
> EDIT@ Right, forgot that that project files got corrupted due to crash. Oh well.
> 

Look like a nice improved addition to the problem. I will try to implement this in my example. Thanks!

Edit: Can't use your algorithm. The reason is we do not have access to the tile data. I am using a tilemap.. there no way to know which tile we going to collide.

I see. Didn't know that. But can you check if tile is solid or not?

EDIT@ You could try using "Compare Tile At" after "Bullet on scree" to check for the tiles you want it to collide with. It might work!

EDIT2@ Also, maybe you could use 2 tilemaps, where one would be for terrain with collisions, other one for the rest!

Here a complete example with fix on some caveat i found while doing it. Look here! After all the performance should not be a problem if you expect to have less than 50 bullets on screen. I will use this in the game since this won't happen.