Bullet Physics in D

Chad J chadjoan at __spam.is.bad__gmail.com
Wed Aug 22 18:58:16 PDT 2012


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).


More information about the Digitalmars-d-announce mailing list