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?

break after return

>>2
He's still resolutely refusing to move. although it has stopped crashing.

just get a this book, use the books code as a starting point
http://www.amazon.com/Game-Programming-All-Jonathan-Harbour/dp/1598632892/ref=ntt_at_ep_dpi_1

>     for (int py = 0; py < 20; px++)
        {
            if (getpixel(image,px+x,py=y)!=bitmap_mask_color(image))

derp

>>5
Oh wow. That's one destructive mistake per LoC.

Stop using C libraries in Sepples.

px++
Where did this habit come from, anyway? K&R uses ++var consistently, most compilers output cleaner code for ++var, and 90% of the time the ++ operator is used without checking its return value, so there's no algorithmic reason to use var++ either.
Is it just a way for Sepplers to rebel against the traditional values of reading books and knowing what you're doing?

I hope xPos and yPos are relative to the other object.
Also, why are you colliding a thing with an image?
Also, why aren't you testing bounding boxes first?
Also, why are you including velocity in collision detection? If either of the velocities are over 40, then there is a chance that they will pass right through each other.

I bet the rest of this dreadful thing isn't any better. 2/10 on a logarithmic scale at best.

>>9
Because I'm in my first year of C++
Velocities are 1.
I can see what you are saying makes sense, and I have now included bounding boxes.
Everyone starts somewhere. I doubt you were much better.

>>10
>>9 was being kind. I would have let you fall on your own sword and then figure it out the hard way. Spare the stick...

>>7
Stop using C libraries in Sepples.

>>8
The language is C++, not ++C. That's seriously why people use the first form of incrementation--it's more immediate in their thoughts.

OP still uses Devcpp.

wwwwwwwwwwwwwwwwwwwwwwww

>>13
your retarded

>>8
derp

>>1
I think bounding boxes is a much better idea than pixel-based collisions, which aren't necessary when sprites are 20x20.  You should also be testing axes indepedently of each other.  In the original example that you had posted, if the player is pulled into the ground by gravity while walking then there will be no motion in the horizontal direction.

You would also want to make your tile collision function generic for all sprites, not just your player.

Also, I would just use C, because C++ isn't necessary for such a simple program.  Make your map an array of char.

>>16
Don't derp at me, cuntbag.

>>17
Listen here, jerkface.

derp

>>8
most compilers output cleaner code for ++var
Sigh. Why must this ridiculous myth be perpetuated? Any competent compiler will produce exactly the same output for either expression if the result is unused.

$ echo 'int f(int x) { ++x; return x; }' > pre.c
$ echo 'int f(int x) { x++; return x; }' > post.c$ gcc -S *.c
$ diff *.s
1c1
<       .file   "post.c"
---
>       .file   "pre.c"
$ rm *.s$ clang -S *.c
$ diff *.s
1c1
<       .file   "post.c"
---
>       .file   "pre.c"
$ rm *.s$ pcc -S pre.c
$ pcc -S post.c
$ diff *.s
$ rm *.s
$ cp pre.c pre.d
$ cp post.c post.d$ dmd -s *.d
$ objdump -d pre.o > pre.dump
$ objdump -d post.o > post.dump
$ diff pre.dump post.dump
2c2
< pre.o:     file format elf32-i386
---
> post.o:     file format elf32-i386
18c18
< Disassembly of section .text._D3pre1fFiZi:
---
> Disassembly of section .text._D4post1fFiZi:
20c20
< 00000000 <_D3pre1fFiZi>:
---
> 00000000 <_D4post1fFiZi>:
$ rm *.o *.d *.dump

Do go on about how the code produced by ++var is in any way cleaner.

(I don't have icc or msvc on hand at the moment, but I have no expectation that their output would be at all different from the above.)

Fucking shitchan, there were line breaks in there.

>>20
Any competent compiler will produce exactly the same output for either expression if the result is unused.
that's only true in c. in sepples, the compiler is required to do a bunch of extra crap if you use var++ instead of ++var.

ITT: Some people don't understand how optimizing compilers work: dataflow analisys, SSA form, deadcode elimination and so on.

>>23
ITT: idiot tries to pass off some terms he heard people use in a discussion about compilers, without actually understanding what any of them mean.

>>8
So what do we do if we want to increment the value of an integer after we've used it in an array?

int i = 0;
int ray[10];
while(i < 10)
{
   ray[(++i - 1)] = i;
}

>>25
@ray=^10

>>25
You'll find that that's undefined behavior.
If it weren't, though, clearly there's an algorithmic reason for using it in that case. There isn't in the 90% of the cases mentioned.

>>25
You write terrible code.

int i = 0, ray[10];
do ray[i] = i; while (++i < 10);

>>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.

>>29
your compiler sucks.

>>30
Those examples were made up on the spot, they were not the output from my compiler. As a matter of fact, most C compilers would generate that code on x86, some would generate inc [ebp+stack_i] in the case the output isn't needed...

>>29
or just stop using those ENTERPRISE grade bullshit terms and hand code from experience

>>10
Everyone starts somewhere, but it shouldn't necessarily be in the language that you heard was "the best," because it is only "the best" for those experienced enough to know what they were doing.
You're right, I wasn't any better when I started out (on a Power Mac aged 10) because I didn't need to be - I was intelligent enough to know that I was shit and that anything I made was likely to be shit, so I stuck to BASIC and the most simple problems that I could solve with a pen and paper before going anywhere near a computer.

Kids these days.

>>28
I was being patronizing.  I'd never push code like that in a legitimate application if you held me at gun point, whether or not it works.

The do...while reminded was welcomed though.  I don't use that often enough.

>>34
I was being patronizing.
No, you were being wrong. Depending on the compiler, your code could produce {0..9}, {1..10}, or a segfault.
You wanted to make a point of suffix ++ sometimes being useful (because you didn't understand the post you were replying to), but instead you just ended up with undefined behavior because you suck at coming up with examples.

>>35
No, what I wrote was intentionally bad.
I assure you I don't have that poor a grasp of what I'm doing.

>>35
I'm inclined to believe him. That code compiles as C, whereas I've only ever spotted PHP programmers (and the odd VB programmer) producing code of that character.

>>37
Consider yourself fortunate to have never met a Java programmer.

>>38
I have, and many. My fortune is that I've never met a programmer who's cut his teeth on Java.

http://www.cheapairmaxs.com air max
http://www.cheapairmaxs.com air max shoes
http://www.cheapairmaxs.com/nike-air-max-2012-c-111.html nike air max 2012
http://www.cheapairmaxs.com/mens-air-max-2010-c-93.html mens nike air max 2010
http://www.cheapairmaxs.com/womens-air-max-2010-c-96.html womens nike air max 2010
http://www.cheapairmaxs.com/mens-air-max-2009-c-95.html mens nike air max 2009
http://www.cheapairmaxs.com/womens-air-max-2009-c-98.html womens nike air max 2009
http://www.cheapairmaxs.com/nike-air-max-2003-c-101.html nike air max 2003
http://www.cheapairmaxs.com/nike-air-max-97-c-94.html nike air max 97
http://www.cheapairmaxs.com/mens-air-max-95-c-102.html mens nike air max 95
http://www.cheapairmaxs.com/womens-air-max-95-c-103.html womens nike air max 95
http://www.cheapairmaxs.com/nike-air-max-93-c-106.html nike air max 93
http://www.cheapairmaxs.com/mens-air-max-91-c-104.html mens nike air max 91
http://www.cheapairmaxs.com/womens-air-max-91-c-105.html womens nike air max 91
http://www.cheapairmaxs.com/nike-air-max-89-c-121.html nike air max 89
http://www.cheapairmaxs.com/nike-air-max-88-c-112.html nike air max 88
http://www.cheapairmaxs.com/mens-air-max-87-c-108.html mens nike air max 87
http://www.cheapairmaxs.com/womens-air-max-87-c-109.html womens nike air max 87
http://www.cheapairmaxs.com/nike-air-max-180-c-123.html nike air max 180
http://www.cheapairmaxs.com/nike-air-max-360-c-124.html nike air max 360
http://www.cheapairmaxs.com/mens-air-max-ltd-c-122.html mens air max ltd
http://www.cheapairmaxs.com/womens-air-max-ltd-c-116.html womens air max ltd
http://www.cheapairmaxs.com/nike-air-max-bw-c-117.html nike air max bw
http://www.cheapairmaxs.com/air-max-premium-c-118.html air max premium
http://www.cheapairmaxs.com/air-max-skyline-c-114.html air max skyline
http://www.cheapairmaxs.com/air-max-zenyth-c-125.html air max zenyth
http://www.cheapairmaxs.com/nike-air-max-tn-c-115.html nike air max tn
http://www.cheapairmaxs.com/kids-air-max-90-c-119.html kids air max 90
http://www.cheapairmaxs.com/kids-air-max-bw-c-120.html kids air max bw

>>8
Looks better.

>>1
Now you have four problems.

DON'T HELP HIM