Tutorial: Pixel-perfect collision with bullets

0 favourites
  • 14 posts
From the Asset Store
Vintage steam pixels for your UI! 125 unique assets in a single pack!
  • 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.

  • Cool

  • Thank you! Very useful!

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

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

  • Rushino zatyka

    Can't check your files at the moment, but wouldn't this be possible using Stepping from Custom Movement behavior?

  • shinkan

    Yes, you are correct. The capx creates a system similar to custom movement's stepping, but only using events. I can't comment on when it would be better to use events vs the custom movement behavior, but if the former is used, it should be frame rate independent. That was the main reason I posted my revision.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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)

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

  • 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?

  • >

    >

    > 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 am not very used to that Delta-time stuff. I though that an event was running based on frame-rate.

    You should then read the tutorial about delta time and framerate independence in depth.

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

  • You cannot guarantee there are no variations in FPS, lots of different computer setups out there. It's best practice to ensure your game functions at low fps as well as 60, else things will break that you never thought of.

    Also on mobiles, definitely no go to design frame dependent games.

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