|
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.
Well, I've been pretty busy with other things today. But I spent a few hours fixing another problem. If you look at the screen shots below, ever since I started working on the collision and block placement, the blocks seemed to have a lot of space in between them. I was a little confused about this because I had used my editor to map the textures to the size that they were supposed to be. It turns out however that somewhere a long the lines I had lost five pixels in length and width on my small blocks. Using math to multiply the bounding volumes was how I got a visual stencil to map my other sized blocks, so the loss of five pixels translated over to 10 in width of the narrow blocks and 10 in width and height for the bigger blocks. This of course is what caused all that space. After figuring that out this morning, I set about fixing it over the last couple of hours. That's done now. Here's a screen shot.
__Click for bigger view__
Ironically all that space actually helped me to develop my collision system though, so it worked out pretty well having that error happen.
Ah.. now that's much better. I still haven't finished the wide spectrum collision, but as I stated I've been busy with other stuff today. I may finish it tonight, but definitely will get it done by tomorrow. I'll be going back to work at a day job next week, so I want to get as much finished over the weekend as possible. More later.
Ok, so I'm still hard at work and making decent amounts of progress.
Yesterday, I took the time to fix proper scaling of the bots in proportion to their game display size in accordance with their actual size on the sprite sheets. I also remapped the textures so that they are now more precise and there are only some minor fluctuations now that your average person probably won't notice, just very slight dither blurring at certain translation locations of the sprites. I was thinking that it's due to floating point error, but I'm satisfied with it for the demo. That actually took most of yesterday to complete and I think I did some more things as well, but I can't really remember so they must not have been to vital.
Today I set back to work on the wide spectrum collision detection for the blocks. What exactly does the wide spectrum collision detection entail you may ask. Well it simply keeps track of the blocks that aren't resting(as in falling), what sector(s) of the block placement area that the block is in. It then looks at other blocks in the same sector and determines which one is underneath a falling block. From there a narrow collision is checked against that specific item. If a collision happens, the falling item is then marked as resting. It works out pretty good.
The second phase of the wide area collision has to deal with updating blocks when blocks below them are destroyed testing if other blocks prevent certain blocks from falling and then entering into the first phase. I guess you could really reverse the numbers for the phases or just call one the top phase which is what I have to finish yet. I got some testing and tweaking to do to it yet. Hopefully that'll be finished tomorrow with minimal effort.
In the meantime, here's a screen of the first phase in action. After the blocks are initially placed on the grid, the collision system now kicks in and the blocks land on top of each other. If you scroll down and look at the picture of the post where I finished the initial block placement, you'll be able to notice the difference.
Click it for a bigger pic. More Later.
Damn it feels good to be a gangsta. I finally, after about a week of doing research into using Separating Axis Method for collision detection, and working on the collision systems for the engine and for Barricade on a whole for about three weeks, finished the narrow pass collision detection. I want to do some cartwheels right now because the whole process was kind of starting to get under my skin. Reason being, I'm no mathematician by any means and the only resources available out there are written from a math theorem perspective. But anyways, I've complained about the process too much as I did it, which if I didn't complain as much I probably would have been finished faster, but it's done.
So.. I can finally go back to concentrating on building a wider spectrum collision management system for the game barricade. They systems already about 75% done at this point, I just have to continue to tweak a few more things. I was worried I wasn't going to make my goal of having a playable proto-type for next months game development forum meeting, but it looks like things should be a go. There's still a lot that I want to get done before an official public release however, but that will hopefully be ready by the first of March or round abouts.
Things that still need to be finished at this point include, but probably aren't limited too..
Finishing the Wide area collision management system.
Remapping some key textures for sprites and animations.
Getting the texture fonts mapped and loaded.(Currently using bitmap fonts for the game.)
Getting some temp sound effects for the demo and getting those inserted into the correct places in classes and adding the proper audio updates.
Replacing the temp graphics made by me with actual graphics made by Dwayne for the game.
Implement the bullets class and resolve bullet to block collision.
Add the ability of blocks to drop powerups and other items upon being destroyed.
Implement chain effects for blocks(Not sure if this one will make it into any of the demos because of lack of information on how this is supposed to work regarding how damage effects different block sizes and Mike Pool is no where to be found for comment.)
Implement powerup effects.(Not sure if this will make it into the demos for the same reason mentioned above.)
Implement gamepads.
Implement general scoring system for the demo.
Create a general level manager in charge of dynamically selecting play arenas and calling the functions related to generating blocks upon the start of new rounds.
There's a lot more stuff to do from there, but once those things are taken care of, a public release of the proto-type will be done. Then we'll have to see how things go from there.
I know after that I need to get back to working on the editor scribe and really start focusing on having the engine be more dynamic and taking care of all the design elements that I made sure to put in place last year. I'll post some screen shots later in the week once I start getting more things up on the screen.
|
|
