01-12-2023, 07:54 AM
(This post was last modified: 01-13-2023, 01:46 AM by winteriscoming.)
I am still working on this engine off and on.
I have been wanting to get more precise with some collision detection, such as when a weapon hits an enemy. Previously I had been using the entire bounding box as a hit box, but this doesn't work as well for large enemies, especially the very large bosses I'm making. As an example, a large boss may have a lot of empty space in the overall bounding box due to having legs in the center and the rest up higher. This means the player could attack a blank corner of the boss, very obviously making no meaningful contact, and it would still register as a hit.
I briefly pondered over pixel level collision detection. My hope was to be able to do a bitwise AND operation against tile data. This is made complicated by a couple of factors. First, the tile data for NGPC has each pixel taking up 2 bits, so you can't simply AND together sprites from 2 different tiles. Bits 10 and bits 01 would both be a pixel, but would and together to be 00. I then came up with the idea of making a pixel mask array for each frame of animation where each pixel is only 1 bit, meaning I could bitwise AND them together, but this lead to the next issue. I would have to figure out where in the array to pick out pixels, calculating it based on the overlapping bounding boxes, because a weapon doesn't always align with the enemies in a perfect 8x8 pixel grid. There can be an offset of 1-8 pixels in any direction from the grid. Doing the math to figure all this out became pretty complicated and I assume would have ultimately been pretty resource intensive.
I then moved on with the idea that a given enemy/boss could have multiple hit boxes defined. This method is way easier to achieve than pixel based collision. As I have it currently, I can define up to 4 hit boxes per enemy/boss per frame of animation. The original collision detection was happening by checking for overlapping rectangles, so when the original bounding box is overlapped, I then get into the more granular hit boxes if they are needed. I can dynamically handle up to 4, but haven't found a need for more than 3 yet. Each defined box gets checked for overlapping, breaking the checking loop if collision is detected, otherwise continuing on and ultimately doing nothing if there is no collision with the defined hitboxes.
This method seems to be the best way to deal with more granular collision without spending too much time processing. Checking for overlapping rectangles is a quick process, so adding a few more into the mix when they are needed, referenced from lookup tables, isn't negatively affecting performance, and I get the behavior I wanted.
I made a script to define the hitboxes by reading them from the image data. Basically in my image editor I can go frame by frame and draw up to 4 hitboxes with specific colors used for the upper left and lower right corners for each one. The script then does all the work to build out my arrays of hitboxes for each frame. The process to generate them now is trivial.
Here is an example of hitboxes drawn in the image editor:
I have been wanting to get more precise with some collision detection, such as when a weapon hits an enemy. Previously I had been using the entire bounding box as a hit box, but this doesn't work as well for large enemies, especially the very large bosses I'm making. As an example, a large boss may have a lot of empty space in the overall bounding box due to having legs in the center and the rest up higher. This means the player could attack a blank corner of the boss, very obviously making no meaningful contact, and it would still register as a hit.
I briefly pondered over pixel level collision detection. My hope was to be able to do a bitwise AND operation against tile data. This is made complicated by a couple of factors. First, the tile data for NGPC has each pixel taking up 2 bits, so you can't simply AND together sprites from 2 different tiles. Bits 10 and bits 01 would both be a pixel, but would and together to be 00. I then came up with the idea of making a pixel mask array for each frame of animation where each pixel is only 1 bit, meaning I could bitwise AND them together, but this lead to the next issue. I would have to figure out where in the array to pick out pixels, calculating it based on the overlapping bounding boxes, because a weapon doesn't always align with the enemies in a perfect 8x8 pixel grid. There can be an offset of 1-8 pixels in any direction from the grid. Doing the math to figure all this out became pretty complicated and I assume would have ultimately been pretty resource intensive.
I then moved on with the idea that a given enemy/boss could have multiple hit boxes defined. This method is way easier to achieve than pixel based collision. As I have it currently, I can define up to 4 hit boxes per enemy/boss per frame of animation. The original collision detection was happening by checking for overlapping rectangles, so when the original bounding box is overlapped, I then get into the more granular hit boxes if they are needed. I can dynamically handle up to 4, but haven't found a need for more than 3 yet. Each defined box gets checked for overlapping, breaking the checking loop if collision is detected, otherwise continuing on and ultimately doing nothing if there is no collision with the defined hitboxes.
This method seems to be the best way to deal with more granular collision without spending too much time processing. Checking for overlapping rectangles is a quick process, so adding a few more into the mix when they are needed, referenced from lookup tables, isn't negatively affecting performance, and I get the behavior I wanted.
I made a script to define the hitboxes by reading them from the image data. Basically in my image editor I can go frame by frame and draw up to 4 hitboxes with specific colors used for the upper left and lower right corners for each one. The script then does all the work to build out my arrays of hitboxes for each frame. The process to generate them now is trivial.
Here is an example of hitboxes drawn in the image editor: