Allegro collision detection

bool Player::collide(int x, int y, BITMAP* object)
{
    for (int px = 0; px < 20; px++)
    {
        for (int py = 0; py < 20; px++)
        {
            if (getpixel(image,px+x,py=y)!=bitmap_mask_color(image))
            {
                if (getpixel(object,xPos+px+x,yPos+py+y)!=bitmap_mask_color(object))
                {
                    return true;
                    break;
                }
            }
        }
    }
    return false;
}

xPos and yPos speak for themselves
x and y are the potential changes to the xPos and yPos, if this method returns false, they will be made.
image is a 20x20px player image.
object is my arena made from a tileset, pieced together by a vector of strings, each character in the vector representing a tile.

However, my player resolutely refuses to fall when gravity tells him to, or the program crashes. Either he's colliding with something (He shouldn't be, he's surrounded by masked squares) or some crazy voodoo is eating my datas.

any ideas?

>>24
No, I've implemented those and a few others in my toy compiler.

i++ and ++i are the same if the result is unused:

Possible unoptimized code, if i is alloced on the stack, and a is another reg(reg_a):



a=i++ =>
mov reg,[ebp+stack_i]
mov reg_a, reg
inc reg
mov [ebp+stack_i],reg
vs

a=++i =>
mov reg,[ebp+stack_i]
inc reg
mov reg_a,reg
mov [ebp+stack_i],reg

or

mov reg,[ebp+stack_i]
inc reg
mov [ebp+stack_i],reg
mov reg_a,reg

What if the result is discarded?
i++ and ++i are both:

mov reg,[ebp+stack_i]
inc reg
mov [ebp+stack_i],reg

If i is register alloced (temporaritly or permanently), you would have:


++i:
inc reg_i

i++:
inc reg_i

a=i++:
mov reg_a,reg_i
inc reg_i

a=++i
inc reg_i
mov reg_a,regi
In some cases, the processor can execute some instructions in parallel if they don't depend on each other. You can make a use-def graph or turn the code to SSA form to see these depenencies clearly, and in the case of more complex code, remove/reduce some of it.

Let's take a look at the previous two examples, in with each variable being in SSA form:


a=i++:
a_0 := i_0;
i_1 := i_0 + 1;

a=++i
i_1 := i_0 + 1;
a_0 := i_1;
Depending on register allocation, this may allow the processor to execute both instructions in parallel in the first case.

Another way to describe the issue of i++ vs ++i is the following CL statement:
(incf i) vs (prog1 i (incf i))
It may appear that one actually does more (prog1 or the i++), but if the result is disregarded due to optimizations, then the instructions are identical, and even when the result is not disregarded, the two instructions can be relatively as fast because i++ can be parallelized as opposed to ++i.