collision point

  • someone must have asked this question but I can't find it..

    I have a sprite shooting a laser.. when the laser hits another sprite I spawn a "hit sprite" which fades out.. looks like a hit effect. I make the end of the laser bolt be imagepoint(1).. so On Collision I set the new hit effect to be at that image point.. the only problem is when something collides with the middle of the laser, it spawns the hit effect no where near where it actually hit! I would have the sprite that gets hit just spawn the hit effect.. but it's pretty large so the same problem will occur.

    I just need to know the coordinates of the collision.. it seems totally possible right?? Or do I have to do some sort of Pick overlap point??

  • One approach is to move the laser backwards until it's not overlapping the other object, then the end of the laser would be the collision point.

  • Search for the rex_light behavior. I believe that it does what R0J0 said automatically. You could use it on the laser sprite it self, or set it on an invisible "detector" sprite just to get the hit.x and hit.y positions.

  • R0J0hound the problem is.. the shooter is moving, therefore the laser is pinned to the shooter (where it grows from). And it grows really quick. The object thats being shot at is also moving. The laser after fully grown just fades out. I do a bunch of them, slightly overlapping one another.. like a sort of auto-laser.

    so the potential objects that the laser could hit, or rather objects that could collide with the laser while it's fading out could easily hit the laser somewhere in the middle as they are going by the extended laser beam. This laser never shrinks (I do have others that do).

    So there's no way to detect collision x/y?? I find that hard to believe.

  • The fact the laser is growing fast or that the objects are moving is not really a problem. The same idea can be used. If the laser at any point overlaps the object, then in with a loop make the laser a little shorter until it's not overlapping the object. At that point the end of the laser is the collision point.

    Another way would be to do a raycast with math, which basically amounts to calculating the intersection points of the laser line and the edges of the object and keeping the closest intersection.

    You could also utilize the chipmunk behavior as it has some stuff built-in to get the collision point. Vanilla C2 collision detection only finds if two objects intersect, at no point is a collision point calculated so you'll have to use one of the above approaches.

  • If the laser at any point overlaps the object, then with a loop make the laser a little shorter until it's not overlapping the object. At that point the end of the laser is the collision point.

    ah okay..I think I see what you are saying-- have the object cut off the laser (like a hand in front of a flashlight) and grow it until they hit the object.. I will try it..

    You could also utilize the chipmunk behavior as it has some stuff built-in to get the collision point. Vanilla C2 collision detection only finds if two objects intersect, at no point is a collision point calculated so you'll have to use one of the above approaches.

    Well that's too bad because it seems like the OnCollision Trigger "knows" there was a collision and must know where it is on the screen. Too bad it doesn't return or populate a system variable like: Sprite.OnActiveCollisionX and Sprite.OnActiveCollisionY

  • R0J0hound how would you do a math raycast in C2? Collision polygon vertices are not accessible to the runtime, or can plugins accomplish that?

    @jobel , one option is to use an iterative raycast method. I believe the best way to do this way is with a binary search, there's example code here:

    https://www.scirra.com/tutorials/902/li ... raycasting

  • [quote:1nb3nvgu]Well that's too bad because it seems like the OnCollision Trigger "knows" there was a collision and must know where it is on the screen. Too bad it doesn't return or populate a system variable like: Sprite.OnActiveCollisionX and Sprite.OnActiveCollisionY

    It doesn't know where the collision occurred, it would have to be calculated in js in the same way as listed here.

    @sqiddster

    A plugin could access the collision polygon. The physics, polygon and chipmunk already do internally. In just events you could place imagepoints in the places of the collision polygon points for a brute force way. Then you can do line intersections with:

    http://paulbourke.net/geometry/pointlineplane/

    I can find a capx where i've implemented it if needed. A plugin could be made to hide the complexity, but I don't enjoy the process of updating and fixing plugins currently.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • thanks sqiddster that looks like a cool capx.. thanks for sharing that. In my case (a space game) all the "solids" are interactive things, so it doesn't save me any performance. I also need to use on Collision opposed to Overlapping because I don't want it to continuously trigger. plus my laser is more like an automatic gun.. it fires long pulses (but beams) and spawns lasers on top of lasers, each laser is somewhat like a 'bullet' and lasts about 0.25 seconds.

    my much simpler solution is: OnCollision with the laser, redraw the laser to the x/y of the colliding object and have the object spawn the "hit effect" (and you have to pin it incase the object is moving fast!). It ends up putting the laser "into" the object more, instead of stopping at the edge. I have an overhead view, so it works. If I end up using this weapon against large sprites (512x512) that's probably not going to work. So I may use that raycaster logic yet!

  • It doesn't know where the collision occurred, it would have to be calculated in js in the same way as listed here.

    bummer..thanks for letting me know..

  • If you want to go the racasting route, here's an example with a re-usable raycaster event group that I've been using. It only needs the Function object to copy over.

    https://www.dropbox.com/s/qfjyoluo4eo83 ... .capx?dl=0

    To use set the start and end points of the ray with "raycast.set ray".

    Then call "raycast.cast to" with the endpoints of every line segment you want to cast to.

    Then use the functions "raycast.get x", "raycast.get y" to get the collision point or the end of the ray line segment if no collision occurred.

  • jobel you might be misinterpreting my capx a bit. It does use 'is overlapping' but the whole thing is wrapped in a function call that you could call how often you want. Also even if all your objects are dynamic the list feature still significantly improve performance since it all happens in an instant.

    @r0j0hound thanks for the capx! looks very neat!

    I wonder if the mathematical method could be even slower than the iterative method in larger layouts (with thousands of collider objects) due to the inability to use the collision cells feature?

  • sqiddster

    It may be slower than iterative methods since calculating intersection points isn't too cheap. With many objects it would be a problem, so any techniques to cull objects you don't need to cast to should help. The main use I have for it is to find an exact point of collision, and also the angle of the edge hit (although that's not present in the capx).

  • sqiddster right okay,that makes sense.. I was thinking it was doing it all the time because of how you call it in your capx example. It's a little overkill for what I'm working on right now.. I have little fighter ships that are doing "fly bys" and peppering the player with a little auto-laser beam (not a continuous beam). But I am implementing a "laser drill" next that I will probably need something like your capx.

    @R0J0hound oh that's interesting, so you are basically defining the collision poly with imagepoints..nice! wow, that does seem a brute force method..but it could come in handy on big sprites where I need the hit coordinates..although in that same line of thinking what if I had 8 image points..I wonder how costly that would be performance wise...

  • jobel

    With 8 instead of 4, then with one ray it would do twice as many intersection tests.

    In general if there is no culling, the number of intersection test will equal=

    (number of rays) * (number of image points)

    So if you increase either then the amount of time will increase proportionally.

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