andriyDev / recastnavigation-rs-sys

Raw Rust FFI bindings for recastnavigation.
MIT License
7 stars 2 forks source link

DtTileCache virtual functions not exposed #8

Closed Sunderous closed 1 year ago

Sunderous commented 1 year ago

Hey, apologies for another one, but this might be on my lack of understanding about how C++/VTables work when dealing with FFI.

I'm trying to make use of the Detour TileCache so I can work with temporary obstacles.

But when I look at the generated code, as far as I can tell this is all that's exposed:

image

So it doesn't appear to have any bindings for the underlying virtual functions that Detour expects you to use when writing a concrete implementation of that DtTileCacheAlloc struct:

image

In their sample, they write their own implementation, which works because it's all C++:

image

Do you know if this is another shortcoming of how the FFI bindings are being generated? Or is there some vtable magic in rust I need to work in order to define my own struct with those functions, and pass it in as a dtTileCacheAlloc pointer to the functions that need it on the C++ side?

Thanks again.

andriyDev commented 1 year ago

Ah yes, this is a limitation of FFI bindings in Rust. However I "fixed" this by adding recast_navigation_sys::ffi_inline::CreateDefaultTileCacheAlloc or if you're feeling fancy recast_navigation_sys::ffi_inline::CreateForwardedTileCacheAlloc. Just don't forget to use recast_navigation_sys::ffi_inline::DeleteTileCacheAlloc once you're done with them!

Edit: the mod ffi_inline hopefully has everything you're missing. Also, don't forget to check out the tests in lib.rs! They have some basic examples (although tbh I don't know if I'm using Detour correctly :P).

Sunderous commented 1 year ago

Derp, didn't even think to look at the tests after I got the normal nav mesh stuff working haha.

Yeah, the example you have in there looks good. Will try just re-implementing from that.

I'm assuming the idea of all the Forwarded variants are that they "forward" the function call/params to our implementations if there's Some() function defined, otherwise just call whatever the original virtual function was (if any) on the C++ side?

And I think I've used 3-4 different implementations/wrappers of recast/detour to varying degrees, and I'm convinced there is no "proper" way to use it :P

Edit: Took your examples, replaced the guts with rust implementations of what they use in their demo (so fastlz compression, and slightly more area/poly flag logic), and I can load a saved tile cache from the demo program, and it at least produces a similar path to my previous vanilla nav mesh test. So I think it's all good, thanks for all the help!

andriyDev commented 1 year ago

Nice nice!

The idea of the Forwarded variants is to just call whatever function you provide for each of the methods in the interfaces - it doesn't deal with inheritance though so if the functions are null that is invalid.

Thank you for trying out these bindings! Happy to help with any other issues!