DebugDraw as an interface?

[GoogleCodeExporter]

Can DebugDraw be made into an interface rather than an abstract class?  Or at 
least DebugDraw implementing IDebugDraw so that our own visual nodes can 
provide it without getting too convoluted? :)

Original issue reported on code.google.com by asheepca...@gmail.com on 2 Mar 2011 at 11:46

[GoogleCodeExporter]

btIDebugDraw is not an interface class although it is called that in Bullet. 
It's really an abstract class as it implements all of its methods except 
DrawLine.

If DebugDraw was an interface then you would have to implement all those 
methods for drawing different shapes yourself, which is pretty convoluted in 
itself. :)

Original comment by andres.traks on 3 Mar 2011 at 7:56

[GoogleCodeExporter]

I see what you mean, but if you keep DebugDraw and make it implement an 
IDebugDraw then all you are doing is giving developers more options by not 
forcing them to use the pre-implemented "shortcut".  Surely not a bad thing? :-)

I guess in a language with multiple inheritance, the way the Bullet folk did it 
makes sense.  In a single inheritance world (like C#) at least the option of an 
interface makes way more sense!

Original comment by asheepca...@gmail.com on 3 Mar 2011 at 8:07

[GoogleCodeExporter]

Hold on, I'm still gathering thoughts about this... :)

I'm still not convinced that the interface class is necessary. In what case do 
you think it would be beneficial instead of using the abstract class?

I wouldn't want to over-engineer the library if possible, because it'll likely 
be more complicated to transfer the drawing calls to interfaces. The DebugDraw 
class contains some base code used to make the callbacks to managed code. A 
class implementing the interface couldn't have this code and so some tricks 
would be needed elsewhere to make this happen.

Original comment by andres.traks on 5 Mar 2011 at 1:02

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Added the IDebugDraw interface in r252.

Original comment by andres.traks on 5 Mar 2011 at 6:01

[GoogleCodeExporter]

Good good :-)

It would be beneficial in any situation where you want add the debug draw 
functionality to a class that already has a base class.  In my case, I want to 
make a scene node that implements a DebugDraw but still subclasses stuff in my 
engine but I can't do it neatly (without making a wrapper).

I didn't realise there were callbacks made in the DebugDraw class... I guess 
that changes things.  What kind of calls do they make to the managed code?

p.s. Just curious, how did you go about making the wrapper?  It's awesome :-)

Original comment by asheepca...@gmail.com on 5 Mar 2011 at 7:21

[GoogleCodeExporter]

Ack, missed your post!  Thanks very much for the change! :-) If you are curious 
- we are using your wrapper for our project over at stexcalibur.com

Original comment by asheepca...@gmail.com on 5 Mar 2011 at 7:24

[GoogleCodeExporter]

; p.s. Just curious, how did you go about making the wrapper?  It's awesome :-)

Thanks! I was looking for a physics engine for a game I'm making in C#, but 
couldn't find any with a permissive licence (zlib, MIT, BSD), so I thought I'd 
wrap Bullet since I'm a big fan of permissive licences. Most of my knowledge on 
this comes from the excellent PhysX.Net wrapper, so props to them: 
http://physxdotnet.codeplex.com

Original comment by andres.traks on 6 Mar 2011 at 5:59

• Changed state: Fixed