Phew! Today was a tough meandering through collision detection and handling responses. After getting fixed point and time-based velocity values, I decided to go through with making that collision detection I worked on the other day. In this one, a rectangle (The ball) in this instance has four conditions with each of the target rectangle's boundaries in which a collision is formed.
With that, one would assume to be finished and just negate velocity? Nope; the question remains as to what direction. This required two more checks, which determined if the ball was approaching from the left or right and thus negated x velocity, whereas the false condition just brought on the y velocity negation.
However! It was not that simple. Negating velocity but not pushing the ball out of the block led to some very strange bits of passing through objects, so I went so far as to apply an impulse to the ball to use its velocity to force itself out of the object, which resulted in an interesting way to speed or slow down a ball's velocity by ramming it with the paddle on the sides.
Once that was through, I kept a byte-sized array of blocks to hold destroyed states, and put in a function to draw the bitmap over them and only check collision if they were not destroyed. All of this worked out nicely, especially with the generic CheckRectCollision function that operated with both the paddle and blocks, leading to this wonder:
But wait! What is wrong with those blocks? The right boundaries are eaten off! I'll have to put in a method to redraw that line soon. Score is also ready to connect with block destruction, and I'll have plenty of refactoring and possible optimizations to make this assembly breakout presentable.
No comments:
Post a Comment