On 08/22/2012 09:06 PM, BLM768 wrote:
I've used Bullet in a professional capacity, and I'd hesitant to force
the GC on your users. I'd port their allocators and supply
implementations that map to malloc or the GC and let users that have
their own heap implementations map them to those.
There are a couple of reasons for this:
1) Most large game engines/simulations probably already have several
types of custom allocators that they'd like to map bullet allocations to.
2) GC is not necessarily the best model for keeping track of physics
data. Usually, physics objects are tied to their game entity
counterparts and should be cleaned up as soon as those go away. This
ownership is mostly unambiguous, so its not much of a burden to
remember to clean up the physics objects. I used ref counting when I
set up my company's implementation but even that is probably not
necessary.
I'll probably mainly keep Bullet's system in place, then. I might at
least replace Bullet's C++ "new" and/or malloc with GC allocations, but
I'm undecided on that.
I don't know much about this library, but what you're saying sounds like
a good strategy. Things in the D ecosystem tend to be safe by default
(use GC by default in this case) but allow for optimizations or low
level tweaking (allow users to supply their own allocators if they want
to).
