Will have a look thanks! However, isn't this useful only if there are variation in the FPS ?

>

>

> So for me it was okay to not use DT since we want it to be dependant on framerate. I don't want that at 30 fps it still reach 300px. That the opposite of what we want to do. I am curious to hear your opinion.

>

I'm curious...what situation would would you want a game to be frame-rate dependent? Objects could move at greatly varying speeds for players depending on their hardware/software, and whatever other game logic is running. Is there a scenario where you'd want the game to play different depending on those factors?

It won't varying. Its locked at 60 fps for everyone. Sure it can drop.. but its okay for the bullet to be speed reduced at 30 fps. Otherwise it will somehow look like it skip frame.

> Sorry i had to post it there because when i try to put it as a tutorial the server crash.. no idea why but there is an error in the loop of an object.

>

Nevertheless tutorials were actually posted. You could have seen them clicking the "Newest" tab.

I deleted two instances so that there's only one remaining.

Sorry then. You should tell Ashley something is wrong with the tutorial posting. This will cause duplicate since i really though it wasn't posted.

I see that you purposely didn't use delta-time, which makes the capx frame-rate dependent. I reworked it a bit to use delta-time, but still end up with a pixel perfect collision.

It should also be noted that the method you use greatly increases the number of collision checks per tick, which could potentially affect framerate.

Sorry i am not very used to that Delta-time stuff. I though that an event was running based on frame-rate.

So at 60 fps mean an event is ran 60 times per second. Which mean after one second at speed of 5 pixels it would have move 300 px per second. At 30 fps mean an event is ran 30 per second. Which mean after one second at speed of 5 pixels it would have move 150 px per second.

So for me it was okay to not use DT since we want it to be dependant on framerate. I don't want that at 30 fps it still reach 300px. That the opposite of what we want to do. I am curious to hear your opinion.

And i agree with the performance, this method is very heavy on collision checks. I would like to avoid this but i didn't find a proper way to do it. So if you don't have 1000 bullets running around you might be fine. This method shouldnt be used on mobile through i am pretty sure it would kill the framerate. (I didn't tried through)

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.

Hi there,

Sorry i had to post it there because when i try to put it as a tutorial the server crash.. no idea why but there is an error in the loop of an object.

So,

This is a short tutorial on how to create pixel-perfect collisons with bullets. I will share my experience too about how its best to make it work.

The idea is basically to use a LOOP to move your bullet instead of using the bullet behavior. This is more precise.

**Important note**

I found something interesting... when you actuall create your bullet be sure it is positionned at an integer value position which mean you have to round it cause it will create problem once it reach the wall. The collision work with pixel integer value so if your bullet is created at lets say x: 233.444 it will move along the non-integer value of .444 and when it reach the wall it will obviously pass the wall off 1 pixel. I am saying this cause this mostly happen if you use the movement behavior as the firing object. Cause that object is never at an integer value so creating your bullet at x,y of that object isn't a good idea. The project option round pixel doesn't seem to fix this issue so be careful.

Thanks to MadFactory since he referenced a MMF base idea on how to do it.

> Hello,

>

> What i wish to do is take Object A angle and set Object B position relative to the angle of Object A at a certain distance (lets say 200pixels) so if the Object A is taking another direction, the Object B must stay at 200 pixels in front of Object A at 200 pixels of position of Object A. The idea is if i am shooting object A that object b could serve as a detector in front of Object A. (This is not a line of sight only a simple detector.)

>

> Any ideas what i can use for this ?

>

> Thanks for your help! Greatly appreciated.

>

you could use the Pin behavior on ObjectB, and pin "position and angle" relative to Object A

Or you could set ObjectB position to :

X: 200*cos(ObjectA.Angle)+ObjectA.X

Y: 200*sin(ObjectA.Angle)+ObjectA.Y

Or even set an object point in the image editor 200 pixels forward the center of ObjectA, and set the position of ObjectB to it.

Work fine! Thanks a lots for your help.

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.

Hello,

What i wish to do is take Object A angle and set Object B position relative to the angle of Object A at a certain distance (lets say 200pixels) so if the Object A is taking another direction, the Object B must stay at 200 pixels in front of Object A at 200 pixels of position of Object A. The idea is if i am shooting object A that object b could serve as a detector in front of Object A. (This is not a line of sight only a simple detector.)

Any ideas what i can use for this ?

Thanks for your help! Greatly appreciated.

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!

(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..

Thanks i will have a look!