We can simply say that this is a small part (only the broad phase) of Box2D.
Most physics engines I know have two phases: broad phase and narrow phase. The broad phase quickly checks for potential overlaps, usually using structural data (like trees), and it’s fast.
If the broad phase detects overlaps, then the narrow phase takes over, using the broad phase results to generate detailed manifolds. This phase is more computationally expensive (and slower).
Physics engines also perform many calculations (mass, force, friction, etc.) to simulate real-world physics accurately. Even if you’re only using it for simple collision checks, it generates a type of rotatable polygon, which can also be quite resource-intensive.
Since this is just a small part of Box2D, we can say yes. But Box2D isn’t that large when compiled, so we’re talking about kilobytes here. I don’t know the exact size difference, as I haven’t measured it because it wasn’t a major concern for me.
If the broad phase alone is sufficient for your needs, then yes. There are simply fewer calculations involved, so you benefit from less costly operations, which can improve speed and allow for more collision objects. And, since it’s only a small part of Box2D, it also uses less memory.
I can’t answer this question for you since I don’t know your specific requirements or where you plan to use it. You might not even need a library for this purpose.
Many people use Box2D because it’s a built-in solution in almost every engine. IMHO, it’s often unnecessary to use a complex physics simulation engine for most 2D game genres, as it can be a poor use of resources.
Finally, there was no Box2D on the C64, Amiga, or even in early PC games. Those developers handled collisions with elegant and often very simple methods because they had limited resources. So why don’t we? This approach gives you more room to polish your game, add more entities, and optimize overall performance.