Quote:
Nope: you just compare the memory position of two objects, independantly of the meaning of that position. So it works in any case! The only thing that could make it fail is if you are recreating objects A and/or B and their position in memory changes.

Wowwww, you are right, it's so cool! I have never heard of it before. In flat memory, despite of DLL, it actually works.

Quote:
Have you tried finding how much the inner collision is costing you? When there are a lot of sprites, this might actually slow down. Maybe you should do a few tests without this inner collision detection?

The data used in test won't cause inner collision, though my program will.

Quote:
I'd also encourage you to use a profiler, if you can.

what's that, and how to use? Could you explain it more? Or a link may help.

A profiler is a program that tells you where your program is spending most of its time. See, for example, gprof as a free/open-source profiler. Profilers help you determine what example is eating up all of your cycles, so you don't spend all your optimization time on irrelevant parts of your program. For example, currently for my program, I know that I'm spending most of my time doing collision detection, followed by drawing sprites to the screen. Thus there's no point in my optimizing, say, my input system.