Collisin Detection

[todor943]

There could be simple collision detection functions without having to include "if" statements.

[jbadams]

I'd prefer this be kept out of SFML itself personally; as a generalised multimedia and windowing library I think this is something that would be inappropriate or would need adjustment for a lot of potential SFML applications.

For simple games or other applications that require this it's often fairly easy to whip up your own quick solution, and in cases where something more sophisticated and/or scaleable is called for it's probably better to look at integrating one of the many existing libraries that offer such functionality.

[Imbue]

I agree with jbadams. I also voted to keep it out.

There are already very good 2D physics libraries that include collision detection. Box2D and Chipmunk are two examples.

[christoph]

I was already skeptical networking was an good idea. While it is certainly nice to have an consistent codingstyle for all the needed libraries in an project I would prefer having SFML rock on graphics and getting other good libraries for other stuff

[Nexus]

but some one in the community could developed a SFML based collision detection lib

How do you mean "SFML based"? Multimedia handling and collision detection/physics are completely different things. So one can develop a collision library independently from any graphics.

By the way, I agree with the other answers. Collision detecting and response is just not part of SFML. There are also too many ways to implement it and a generic solution is difficult without writing really much code. To prevent if statements in user code, you can either use an external library or write your own collision manager.

[quasius]

There is plenty of math tools in right now, like checking if 2 sprites overlap, and Vector 2D, just use that as a base, and format the lib like SFML. Thats all I mean. Like a CD lib that takes SFML sprites and uses their data to do CD.

That would amount to little more than an OBB-to-OBB overlap test.  Such a simple function might be worth including, except then people who don't understand CD would start complaining that it's not "pixel-perfect" or something.  Implementing a "pixel perfect" test is a bad idea since it's a stupid, stupid way to do CD and would quickly start bogging down any CPU.
Breaking down visible sprites into polygonal/circular collidables (the correct way to do CD) is clearly beyond the scope of SFML.

Edit:  I suppose I could publish my 2D CD library to the wiki if someone wants light-weight 2D CD without a full physics simulation (Box2D).  But breaking up the sprites into polygons will always be the responsibility of the user since automating that task is not even remotely trivial.

[Dig]

I've put some sample code up on the wiki regarding collision detection, not sure if its the kind of thing you're after.

http://www.sfml-dev.org/wiki/en/sources/simple_collision_detection

while pixel perfect collision detection isn't necessary all the time (and is indeed CPU hogging overkill in most situations) there are times when it is needed and acceptable to use despite quasius's intense hatred of it.

The code I've put on the wiki isn't the best for using pixel perfect detection heavily but its perfectly usable sparingly on any thing I've tried it on.  The Circle, AABB and OABB tests are much quicker and cover most situations on their own.  This system won't easily let you breakdown sprites into polygon primitives for detection but might be worth using as a start in the absence of any other code.

I've started looking at bitmasks for pixel perfect collision, but I need to improve my maths skills for rotations and translations

My version certainly isn't as fast as PMASK but to prove that pixel perfect collision detection can be done, the PMASK test happily does realtime collisions between 21,000 objects on my machine without even blinking.

http://sourceforge.net/projects/pmask/

Edit:  Just re-read the start of this thread.  I think any collision detection solution should be completely separate from the core of SFML.  Its not really the type of thing a media layer should be responsible for.