Starting Box2D 3.0 | Hacker News Reader

Starting Box2D 3.0

box2d.org

76 pointskristoff_it7 comments

> Another benefit of speculative collision is that I can elminate[sic] the polygon skin/radius on collision shapes. That was necessary to keep shapes separated for the time of impact algorithm. This should no longer be necessary in version 3.0. I never liked this artificial separation of shapes.

Hah! In Planimeter Game Engine 2D, we shrink physics objects by the polygon skin slop so that we can achieve "pixel approximate" physics.[1] We keep sprite sizes the same and as a result there's no visible separation of objects, but Box2D continues to safely separate objects.

afaik, we're the only engine that does this with Box2D, and I think the results end up superior.

[1]: https://github.com/Planimeter/game-engine-2d/blob/master/eng...

Exciting! The use of C will make it easier to bind from my language of choice.

He should have kept the better type safety from C++ and expose C like API surface, as actually libc is implemented by MSVC and clang.

No big rewrite effort, better type safety.

Get ready for CVEs.

The C++ code in the previous version was already C-style anyway (and nothing wrong with that), and returning pointers from the API would have been a very likely cause for memory corruption problems if the API is 'misused'. It's more likely that the new handle-based API will improve memory safety drastically (assuming they're tagged index handles which provide both spatial and temporal memory safety at the cost of minimal runtime overhead for each API call which needs to convert handles to pointers - which costs a range check, a tag comparison, and an array indexing operation).

It is like asserting using C structs with function pointers is safer than a C++ struct with member functions.

I don't understand? Why would function pointers or member functions be involved in a plain C API (unless you want to create one of those ugly "let's wrap an OOP C++ API in a C API" attempts where each C++ method maps to a C function with a "this" parameter or have "virtual function tables" - essentially emulating C++ in C, which really doesn't make much sense).

As for the memory safety aspects: When returning raw pointers to internal objects from an API, those pointers can become dangling.

C++ smart pointers are not a solution because those cannot be expressed through a C API for language bindings - also there's the question what type of smart pointer to return - unique vs shared? That should be up to the API user, not dictated by the API.

Tagged index handles solve all those problems in a very elegant way - and they work equally well for C, C++ or any other language that supports arrays, and since those handles are essentially just integers, they are trivial to tunnel through FFI (see for instance: https://floooh.github.io/2018/06/17/handles-vs-pointers.html)

It is hardly better than having opaque handles that translate into C++ classes, with proper validation of invariants.

I know how well they work in C, having worked on a RPC server for IVR/CRM middleware using similar approach for shared memory IPC across UNIX/Windows multiprocess, and having my share of fixing memory corruption issues in collaboration with our QA team nicely written attack tests in Rational Robot.

I guess instead of using Purify and BoundsChecker, now the fun will be with ASAN.

Reply on news.ycombinator.com