Page 6 of 6 FirstFirst ... 456
Results 76 to 80 of 80

Thread: C++ SDK - When?

  1. #76
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,613
    Quote Originally Posted by jay3d
    It would be useful at the start before building D wrappers around the SDK code, to make the programmer gets familiar with D first
    That wouldn't be a wrapper though, just an interface of D into the C SDK.

    A wrapper would mean encapsulating all of the SDK into D classes.

    Cheers,
    Mike

  2. #77
    Member
    Join Date
    Apr 2003
    Location
    Fredericton, NB, Canada
    Posts
    169
    I use C++ for all Happy Digital plugins. I also use a wrapper to do this. That way, I don't have to cut-and-paste any of the initialization code, etc. A simple shader plugin can be implemented in just a few lines of code, total.

    You knew that already, LightWolf

    The wrapper I wrote is completely lightweight, meaning it uses all original LightWave structures in memory, but interprets them as my wrapper classes. The wrapper never adds any extra copying or indirection that wasn't already in the SDK. There is absolutely no performance hit. And the shorter, cleaner code that I get from my C++ style makes things very easy to maintain for me.

    However, NewTek seemed to do alright using C to build LightWave, so go ahead and use that if it suits you.

    - Graham
    - Graham Fyffe
    proprieter, Happy Digital

  3. #78
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,613
    Quote Originally Posted by fyffe
    You knew that already, LightWolf
    I did

    And one day... we'll merge our wrappers ... one wrapper to rule them all (I'm just afraid that they might be designed too different...)

    Cheers
    Mike

  4. #79
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,898
    Quote Originally Posted by Lightwolf
    And one day... we'll merge our wrappers ... one wrapper to rule them all (I'm just afraid that they might be designed too different...)
    I am still opting for maximum integration architecture f.e.:

    Code:
    class LWCCommandSequenceTest : public LWCCommandSequence 
    {
     public:
      LWCError Process( void )
      {
       Evaluate( "MAKE_BOX <0,0,0> <1,1,1>" );
       return( errorNone );
      }
    };
    
    LWCCommandSequenceTest pluginTest( "Test" );
    Have no more ServerDesc[] table, and build it in real-time in plug-in activation function..

    The all LW plugin classes put into corresponding to it LWC<name> class, and to have them as LW plug-in just sub-class it, intercepting the main essencial routines and do something in them..

  5. #80
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,613
    Quote Originally Posted by Sensei
    I am still opting for maximum integration architecture f.e.:
    That's basically how mine works without the fancy plugin-activation... I just didn't have time to design it to behave for all the cases that I have in mind.

    No reaons to use a prefix though, C++ supports namespace.

    Cheers,
    Mike

Page 6 of 6 FirstFirst ... 456

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •