[ODE] 0.9-rc1

[Oleh Derevenko]

Bram, that's OK, but I don't think it is worth copy-pasting such large functions. If you consider how many operations they include, adding one more extra call to make dNormalize a simple wrapper would not have any performance influence. Furthermore, if you implement dNormalize in header and mark them as "inline", they will be inlined and will not generate even that extra call.

So, I'm moving dNormalize implementation to header and making it look like this:

static inline void dNormalize3(dVector3 v)
{
    int iNormalizationResult = dSafeNormalize3(v);
    dIASSERT(iNormalizationResult);
}

Oleh Derevenko
-- ICQ: 36361783

  ----- Original Message ----- 
  From: Bram Stolk 
  To: Oleh Derevenko 
  Cc: ode at ode.org 
  Sent: 7 жовтня 2007 р. 18:37
  Subject: Re: [ODE] 0.9-rc1


  The demos are fine with zero vec normalization asserts.
  I have added dSafeNormalize3() and dSafeNormalize4() that will not assert, and return success.
  The dNormalize3() and dNormalize4() are back to their old void funcs, with asserts added. 

    bram



  On 10/7/07, Bram Stolk <b.stolk at gmail.com> wrote:



    On 10/7/07, Oleh Derevenko < oder at eleks.lviv.ua> wrote:

      First of all, you are expected to build release with assertions turned off.
      So you can be sure user will not see assertion failure.



    That's a very good point.

    I take it that distro's like Debian build with --enable-release 
    So currently, I am leaning towards asserting zero vector normalization.
    I will add the asserts in my dev tree, and check all the demos.
    If no demo asserts on it, I will submit it to the trunk.

      Bram



    -- 
    Zapp: Captain's log, stardate...er..
    Kif: Ohhh. April 13th.
    Zapp: April 13th. Point 2. 



  -- 
  Zapp: Captain's log, stardate...er..
  Kif: Ohhh. April 13th.
  Zapp: April 13th. Point 2. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ode.org/pipermail/ode/attachments/20071007/594dd1b6/attachment.htm