Wide Area Collision Problems Resolved - In Theory

I was up very early today and began setting back to work on the second phase of the wide area collision. There were three problems that I came across during that time and after resolving them I figured I was done. I tested it a few times and after a while I began to notice the blocks were doing some interesting things. Interesting meaning doing things that they shouldn't have been doing.

Things being that they were falling in the correct spots, but for some reason certain blocks were only partially falling to the point they were supposed to before being marked as at rest, so they were being suspended in mid air, which meant a collision was happening and they were hitting the blocks directly below them, as the system is designed to check for, but I was a little confused on why. So, I took a break from the collision for a while searched for some new fonts, did a little bit of texture mapping, had lunch, and then came back to try and tackle the problem.

I've found that from time to time when I do get stuck, it's a good approach to move onto something else, and then I can come back later and look at the problem without as much stress and a fresh set of eyes. In this case I was actually going to finish implementing the bullet class so I could shoot multiple blocks to help figure out what was going on, but as I sat down to do that it dawned on me that my design for a two phase wide area collision system was flawed.

In the current system there are 2 phases, phases in this instance can also be translated to 2 large code blocks.

The first phase consists of looking to see if a block is marked as no longer being collide-able. If it is marked it's then marked to be destroyed. It then cycles through every block checking to see if it is in the same y cell column and that no other blocks would stop that block from falling. If those criteria are met then the block is marked to fall, grid location is updated depending upon the size of the block being destroyed, (the size of the block being destroyed tells us how many cells our other blocks should fall), and that's it for the first phase.

The second phase is where actual collision tests take place based on sector locations as well as actual updating of the blocks positions. Designing these two parts separately was a mistake however because of the way in which the blocks are placed on the grid to begin with. It's done somewhat randomly, placing blocks where there is no block and where there is room to place them. Meaning that having the second phase executed outside of the first phase causes the wrong blocks to fall first. This results in premature collisions, which results in the suspended blocks.

For example :


|_2_|

|_3_|

|_1X_|

Block one is the one being destroyed and blocks 2 and 3 are marked to fall.Because the blocks are out of order, when we reach the second phase, block 2 is checked for collision first and moved first, meaning, that since block 3 hasn't moved yet a premature collision happens. This may not happen every time, it depends on where the block is that is being destroyed and where the blocks that are falling are located, but it's an obvious design flaw.


So, the solution then, which I'll begin working on after this post is to combine the two phases together. Even though the blocks are iterated through in the first phase, we start with the one directly above the destroyed block, so, if I start moving these blocks as soon as they are found, then the premature collisions should no longer happen. At least that's what I'm thinking right now. I guess I'll find out soon enough.