Open GoogleCodeExporter opened 9 years ago
To start things off, here's a simple patch that wraps all the allocation
functions in extern "C" {} blocks.
Original comment by richard....@gmail.com
on 8 Dec 2010 at 10:13
Attachments:
Here's a .cpp file that, when built with the rest of the code in a DLL project,
should export the NavMesh, NavMeshQuery and QueryFilter class functions in a
C-callable manner.
I generated it using SWIG and a really yucky XSLT that I wrote, also attached...
Original comment by richard....@gmail.com
on 9 Dec 2010 at 12:03
Attachments:
I generally agree on C API. What I'm worried about is how to keep it up to date
and how to make it compile on win/mac/linux (I don't think
__declspec(dllexport) is not portable).
I'm currently struggling to keep all the version up to date since I don't have
a linux box or windows machine to test on.
Ideally I would like someone else to maintain and support the C API. I wish I
could the same for win32 projects and linux make files too :)
What is that xslt used for?
Original comment by memono...@gmail.com
on 9 Dec 2010 at 8:29
The XSLT is used to transform the output from SWIG into C, as SWIG's built-in
support for C is not yet released. That's how I propose keeping it up to date:
have it be automatically generated by using SWIG and MSXML, as an automatic
build step. The XSLT is yucky because I've put in a load of stuff for working
around bugs in SWIG's handling of the C++ type system and for filtering out
classes/methods that we don't want to expose in a C API.
I can have a crack at writing up the necessary build scripts, if you like - I
can give you VC++ 2010 project files too, if you want, though I appreciate that
maybe you don't want to do that if they're going to get out of date. (Or I can
write a Mac-compatible script that generates a VC++ 2010 project file :D).
Original comment by richard....@gmail.com
on 9 Dec 2010 at 2:14
Hi,
Now that Christmas is finally over and I have been able to flush my most urgen
todo list, I'd like to find a solution to this.
Ideally I would like to have a script which I could run before I make a commit
which would do all the magic. Supporting all the features and platforms is my
biggest bottleneck currently.
Also, I would like to (eventually) include Recast C API too for the sake of
completion. The debug draw stuff is super valuable, so ideally I would like to
have that too. And a cheeseburger, please! ;) I'm not sure how a virtual
interface (duDebugDraw) would look through C API, though.
Are there any nasty things in the C++ APIs which I could fix to make the C API
easier to build?
Original comment by memono...@gmail.com
on 3 Feb 2011 at 10:14
Welcome back, hope you had a good Christmas.
As far as Detour is concerned, the only nontrivial bit I can think of is the
virtual function stuff in dtQueryFilter. It'll still be very useful for C
clients to provide their own passFilter/getCost implementations, but they'll
have to do them as free-standing function pointers. I don't think this'd be too
hard to arrange - create a subclass of dtQueryFilter that forwards to the
function pointers - though there might be a more efficient way...
Everything else maps fairly neatly to an 'explicit this' idiom, i.e.
dtNavMesh_method(dtNavMesh* self, ...)
From a script point of view, my SWIG approach is very overcomplicated (I was
mostly trying to avoid changing any of your code, to make upgrades easy). It
should be possible to tag all appropriate method declarations with CAPI or
something, and then grab and parse them with a bit of regexp magic. I'll have a
look at this once I've got some time, if you like.
Original comment by richard....@gmail.com
on 9 Feb 2011 at 9:48
Hi!
I'm interested in using detour as a DLL. Has any progress been made on the
ideas mentioned in this issue? If not, are you still interested in having
something that works as described in the 5th comment ?:
"Ideally I would like to have a script which I could run before I make a commit
which would do all the magic. Supporting all the features and platforms is my
biggest bottleneck currently.
Also, I would like to (eventually) include Recast C API too for the sake of
completion. The debug draw stuff is super valuable, so ideally I would like to
have that too. And a cheeseburger, please! ;)"
Have a great week-end!
Original comment by julien.g...@gmail.com
on 1 Oct 2011 at 2:29
We only have ponies, is that ok? ;)
I have not had enough time to look into this. If someone wants to take a stab
at it, I'm willing to include patches, etc. Unfortunately I don't have enough
time to look into the C API and to maintain it for all the platforms.
--mikko
Original comment by memono...@gmail.com
on 1 Oct 2011 at 4:11
Alright, thank you very much for your answer. I will look into it and maybe
I'll be able to find some time to do it.
Original comment by julien.g...@gmail.com
on 3 Oct 2011 at 12:50
For the time being, could we get the dtAlloc*/dtFree* functions (i.e.
dtAllocNavMesh/dtFreeNavMesh, dtAllocNavMeshQuery/dtFreeNavMeshQuery, etc)
wrapped in 'extern "C"' blocks? I expect they'd end up being exposed as part of
a C API in their present form anyway, so once they're wrapped in those blocks
they're good to go.
For now I just have to remember to keep patching them every time I pull the
latest code, but it would be nice if I didn't have to do that ;-)
Original comment by richard....@gmail.com
on 30 Mar 2012 at 11:27
Can you post me a patch so that I definitely get it right?
Original comment by memono...@gmail.com
on 1 Apr 2012 at 9:46
Sure, here it is; but I'm using recastnavigation via Git, so the patch file
format may not be compatible with your tools. I'm not sure how to apply it
directly to SVN, short of getting the SVN toolkit and checking out a fresh copy
of the codebase and making the changes again.
Original comment by richard....@gmail.com
on 2 Apr 2012 at 1:48
Attachments:
Original issue reported on code.google.com by
richard....@gmail.com
on 8 Dec 2010 at 9:27