Monday, August 16, 2010

Heads Up, API Changes Coming Soon

I try to get two API breaking changes done this week.

1) Recast Context: This change will add additional parameter to most of the recast calls. I have yet to decide if the parameter will be the first or last. The idea behind this change is to remove platform dependancy of error/warning logging, timer and profiling code from Recast. See:

2) dtNavMesh & dtNavMeshQuery: This change will allow multiple simultaneous navmesh queries to happen at the same time. Basically it will strip dtNavMesh to just the data management, and add new class which has all the query functions. This makes Detour more concurrency friendly. See:
I will make separate posts describing the changes once I get things checked in.

4 comments:

  1. My only comment is it might be nice to wrap things like log output messages in macros so they can be compiled out of shipping builds. I'm not using Recast at runtime but if I was I think I'd want this.

    ReplyDelete
  2. Actually, I lied about only having one comment. An abstract interface might be overkill for a timer given that it probably doesn't need runtime polymorphism. A common header with different implementations for each platform would suffice. I always try and avoid virtual methods where possible :)

    ReplyDelete
  3. Cam, I had really good plan to tackle this, and now I have to rethink! ;)

    Currently the timer is implemented as platform specific code. The problem is that it is not possible to plug some engine timer without changing the timer file (I'm sensing friction against doing that).

    So the abstract interface here is just a c++ way of saying: function pointer.

    ReplyDelete
  4. I wouldn't let it throw you, it's a very minor point. I think I haven't really read the background discussions that thoroughly. If people want to provide custom timers then what I'm talking about isn't really appropriate.

    All I meant is, if you have an interface like so:
    struct Timer {
    virtual Time GetTime() = 0;
    }

    And then a bunch of concrete classes like:
    struct WinTimer : public Timer { ... }
    struct MacTimer : public Timer { ... }
    struct XboxTimer : public Timer { ... }

    On the premise that you are always going to use the WinTimer on Windows, you can ditch the Timer interface and just do:

    #ifdef WINDOWS
    typedef WinTimer Timer;
    #elif...
    #endif

    Or alternatively a common Timer.h and platform specific TimerWin.cpp that provide implementation.

    In the scheme of the changes you are making it's not important :)

    ReplyDelete