Seems like this "hardcore" myth is unkillable ::)
Just to prove how simple and powerful Boost.Geometry is:
namespace bg = boost::geometry;
typedef bg::model::d2::point_xy<float> Point;
typedef bg::model::polygon<Point> Polygon;
// Create polygon geometry
Polygon polygon;
bg::append(polygon, Point(x0, y0));
bg::append(polygon, Point(x1, y1));
...
// Create point geometry
Point point(x, y);
bool pointInPolygon = bg::within(point, polygon);
And please don't complain about the type definitions, you have them a single time in your code and that's it. On the contrary, this allows you to use arbitrary geometry types. For example, you can easily make everything based on sf::Vector2f, to integrate your entire geometry logic with SFML in a matter of minutes.
Seems like this "hardcore" myth is unkillable ::)
Just to prove how simple and powerful Boost.Geometry is:
namespace bg = boost::geometry;
typedef bg::model::d2::point_xy<float> Point;
typedef bg::model::polygon<Point> Polygon;
// Create polygon geometry
Polygon polygon;
bg::append(polygon, Point(x0, y0));
bg::append(polygon, Point(x1, y1));
...
// Create point geometry
Point point(x, y);
bool pointInPolygon = bg::within(point, polygon);
And please don't complain about the type definitions, you have them a single time in your code and that's it. On the contrary, this allows you to use arbitrary geometry types. For example, you can easily make everything based on sf::Vector2f, to integrate your entire geometry logic with SFML in a matter of minutes.
Yes, you can make everything based on sf::Vector2f. Have you done this? If so, would you share your efforts with the community by any chance?
I am asking, because this has been on my mind for a while. My own efforts are not quite as polished as I 'd like, i.e. a uniform treatment of sf::Shape, sf::Sprite, sf::VertexArray and user-defined ranges of sf::Vector2f. And it required definining metafunctions.
Not that I disagree with your other points. Boost libraries are not only a way to avoid reinventing the wheel, they are also instructive; some APIs are controversial, even among Boost developers themselves, however there are always reasons why things are the way there are.
On the other hand there is no substitute for the instructive value of hand-implementing something; only then you get to wrestle with the problems and truly understand the implementation, performance considerations as well as interface choices.
To follow up on the matter of Boost.Geometry, I have put some of my efforts here (https://github.com/Kojirion/SF.Boost.Geometry).
sf::Vector2f is adapted to model the Point concept, very simply with the macro BG provides.
sf::FloatRect is adapted to model the Box concept (https://github.com/Kojirion/SF.Boost.Geometry/blob/master/include/Box.hpp). (the macro can't be used out of the box, as BG represents the Box in terms of bottom left and top right corner, rather than top left and size)
Already by doing these two, it is possible to insert the FloatRect into BG's rtree (a spatial indexing structure like a quad tree). An example of using the tree to determine collisions can be seen in this rudimentary invaders prototype (https://github.com/Kojirion/SF.Boost.Geometry/blob/master/examples/invaders.cpp).
The rest is unfinished, as an ideal design is not clear. I think that rather than registering SFML classes as any particular geometry, there should be lightweight 'views' that are registered instead, so that for example a sf::Shape may be viewed as either a filled or unfilled polygon. A sf::VertexArray could be a polygon but also just a linestring, etc
One neat free side-benefit is that registered geometries can be output in pretty text or SVG. For example
sf::FloatRect rect(0.f, 10.f, 10.f, 10.f);
std::cout << bg::wkt(rect) << '\n';
gives
POLYGON((0 0,0 10,10 10,10 0,0 0))