By "collision detection" all I meant was that there should be something like a flag on an sfml sprite / shape / anything that has a bounding box that tells me whether it is intersecting with anything else that has a box/shape/area, if I pass a flag to the shapes/boxes involved telling them to "turn on collision detection for this entity" in the constructor.
That doesn't really complicate the API at all and the performance penalty under the hood for managing the intersection system is opt-in.
How does adding parameters to the API that not everybody might use in a typical use case not complicate it at all? You are already making a lot of assumptions that do not hold in most scenarios outside of game development. Does everybody deal with entities? What if they have their own more sophisticated entity system? If people build GUIs with thousands of graphical elements, there will be unused data members in every single one of them, not to mention the inactive data paths that imply unnecessary checks. It simply can't be "opt-in" if the system is "activated" from runtime data (parameters) as opposed to statically via the preprocessor/templates.
This has lots of applications outside of games because as you said, it is just intersection detection.
Providing concrete examples would help to convince people, and allow them to debate over whether those examples are actually valid.
Currently sfml intersection detection requires you to query for an intersection between two provided shapes. What I am suggesting is that querying for intersection is slow and can often be complicated if the entities in question are not localized to a single data structure, and it would be simpler if "intersection" were a property rather than a return value. In other words, the shape/sprite/whatever just "magically knows" whether it is intersecting or not, because work is being done behind the scene to update that property based on all other registered shapes/boxes/whatevers.
The user doesn't have to know how the shapes/boxes/whatevers are implemented underneath and inside SFML, only SFML does has to know that. And SFML can exploit that knowledge to provide more efficient persistent intersection detection that the user could.
With each of your statements, you are becoming more and more application specific. Why would entities have to be localized to a single data structure? Sure you can do this in your own code, but how would others actually benefit from this? Not to mention, like I said... the concept of "entities" doesn't even apply to every scenario.
Also, you can't simply say "whether something is intersecting or not". It simply doesn't make sense.
With what is
what intersecting? An intersection in set theory is the set which contains the common elements from
2 or more sets. Intersection is a binary operator, so if you wanted to register whether an intersection persists between 2 "entities" you would have to at least store it as a bool along with information about the counterpart as well. In the simplest scenario, you would be checking for intersections between "active entities" (those for which checks are enabled) between
every possible pair of entities in your container since the "checking" entity has no knowledge of whether the target entity is actually registered for checking. I hope I don't have to explain how this grows quadratically... You might say: Well... all the registered entities are referenced in a separate container so they don't have to check for this. Then I have to ask: Doesn't this contradict what you initially said about everything being in a single data structure?
Under the hood this allows SFML to use temporal coherence for efficiency. Temporal coherence is the property that two intersecting shapes will likely be intersecting next frame, and two non-intersecting shapes will likely be not intersecting next frame. A query based approach does not exploit temporal coherence-- you have to keep querying whether the two shapes intersect over and over in order to determine when the shapes stop intersecting or start intersecting.
Even more application specificity... What does temporal coherence mean to those who simply don't care? Does it even make sense to speak of such a thing if you aren't ticking a simulation every frame?
The benefit of offering something like this through SFML is that collision detection systems of choice can be built on top of it. For example, to get sweeping collision detection for bullets you can create a new sfml::shape who's outline is the outline of the swept out area of the bullet along its trajectory. It is totally up to you how you want to determine or compute that swept out shape, but the intersection part of the problem is solved on the SFML side, rather than the application side.
Even you are bringing up the topic of collision response now. Like I said, these things are tightly coupled. Someone who goes through the effort of implementing the second half (which is probably the substantially bigger part) will not be bothered by implementing the first half themselves as well. There is no point in providing something for people to use "just so they can make use of the library more". We don't want to lure people into using something that might even be suboptimal for their specific scenario, and given the wide variety of collision detection implementations this will almost certainly be the case.
There is no reason that intersection HAS to be a query. Query is just one tool in the software engineering toolkit. It isn't the best one for intersection testing for most multimedia applications in my honest opinion-- a persistent state model would be better.
You should really try to think outside the box when you say something like "for most multimedia applications". I can't really tell whether you have actually considered anything besides the very specific use case you have presented here. Bear in mind that this toolkit will have to be used by many many people with very different requirements. If I go to a hardware store and get a set of tools to undertake some home improvement, I'm definitely not going to wheel home half a car of tools that the salesman told me might be useful before even knowing what I was intending to do
.
