Linux compatible .Net bindings for irrLicht

[jimmy00784]

Some C++ templated classes did not generate complete C# classes so I created proxy classes to do the conversion for at least those classes that were needed to get some example classes to work.
If C# classes can be generated, probably by using some of your patched header files, respective proxies won't be necessary.

And by the way, I had initially started out with the -includeheaders flag for SWIG, as you suggested earlier, to automatically include all modules, but then opted to include them manually since I was getting build errors while compiling the generated C++ code. So I instead went the approach of manually including the modules, rearranging them for inheritance, and disabling some that caused errors in C++ to attend to at a later time.

[roxaz]

well i have most of errors fixed. atm im at the point where had to make two classes public in irrlicht headers

Code: Select all

 
typedef irr::scene::CVertexBuffer::IVertexList IVertexList;
typedef irr::scene::CIndexBuffer::IIndexList IIndexList;
%{
typedef irr::scene::CVertexBuffer::IVertexList IVertexList;
typedef irr::scene::CIndexBuffer::IIndexList IIndexList;
%}
 

then this

Code: Select all

%ignore irr::video::IGPUProgrammingServices;

and two typecasts void*->wchar_t (manually done).

thats with -includeall atm battling with qmake, for some reason it wants to link src.obj grrr. otherwise it should compile at least.

[jimmy00784]

For making the private classes public, you'll probably have to rewrite them again as public for SWIG similar to what you did for you patched files. Since these modified classes are only used to generate wrappers, and the actual irrlicht codebase is left untouched, you should be fine.

[roxaz]

pretty much what i did.. still cant figure out how to make this IEventReceiver an interface. what i have so far:

Code: Select all

%nodefaultctor IEventReceiver;
%typemap(csbase, replace="1") IEventReceiver "";
%typemap(csclassmodifiers) IEventReceiver "interface";
%typemap(csbody) IEventReceiver "";
%typemap(csfinalize) IEventReceiver "";
%typemap(csdestruct) IEventReceiver "";
%typemap(cscode) IEventReceiver
%{
    public bool OnEvent(SEvent event);
%}
%typemap(csinterfaces) IGUIElement "IAttributeExchangingObject, IEventReceiver";

neither IEventReceiver becomes interface nor IGUIElement implements it. i surrender..

[jimmy00784]

Don't worry about IEventReceiver. For the 3 classes that inheirit it, just change the generated C# code for them from "override OnEvent" to "virtual OnEvent". Since those are base classes anyways, there will not be very many ocassions when you'd want to implement your own anyways. Also, I think the override to virtual change will take care of it in the event you do wish to inheirit from them since that'll more than likely (some testing needed) cause the inheritance to be managed within native C++ library rather than the C# wrapper while still exposing the necessary virtual method to allow C# code to handle event handling.

[roxaz]

btw greenya expressed any interest in this?

[jimmy00784]

No one has contacted me yet about this. The progress is certainly noteworthy, all thanks to your help. I'll approach them once we have a functioning setup if they contact me in the mean time.

[greenya]

btw greenya expressed any interest in this?

I'm here. What do you need?

[roxaz]

No one has contacted me yet about this. The progress is certainly noteworthy, all thanks to your help. I'll approach them once we have a functioning setup if they contact me in the mean time.

you mentioned you would pm him thats why i asked ^_^

btw greenya expressed any interest in this?

I'm here. What do you need?

we were just wondering if you had any interest in .NET bindings that would be cross-platform. if so - maybe we could all work together to craft something useful. while IrrlichtLime is outstanding its only for windows due to it's mixed mode nature.

[greenya]

Well, i don't think i can help you here, because i don't know what is SWIG, and how do you plan to compile managed c++ on Linux. That is beyond my understanding

[roxaz]

well - managed c++ compiled with /clr:safe run on linux just fine as they are pure .net binaries w/o bit of native code. in case of lime - you cant have that because of needed mixing of native code to consume native classes by managed code.

now what swig does is generating c wrapepr around c++ api. then it generates bunch c# wrapper code that calls this c interface using pinvoke. c wrapper then is compiled with native compiler to dll (win) or so (unix). so no managed c++ is in action with swig really

[jimmy00784]

roxaz, once you have got c/c++ wrapper to compile (with or without the two classes causing problem), let's get your changes merged. We can then start adding some examples to demonstrate how to use IrrlichtDotNet. I am thinking of using the examples from irrlicht tutorials. Once all the tutorials are working against IrrlichtDotNet, it might generate more interest in the project.

[roxaz]

cxx compiles, provided two typecasts are changed from (void*) to (wchar_t*)

[jimmy00784]

roxaz, I took your python script that creates the C# project as well created my own make.sh inspired by your make.sh.
I think I am going to pursue down the road of explicitly calling %include on all necessary modules. By the way, I've started using typemaps more often. I have been able to map almost all irr::core::stringc occurances to System.String for both inputs as well as outputs. Only item left is SJoystickInfo.Name which gets translates as a Property in C# and still uses SWIGTYPE_p_[...] class object that SWIG creates for stringc under .Net. The idea is if I eliminate all SWIGTYPE_p_[...] objects by typemapping them to proper .NET objects, there won't be any need for creating proxy classes to help with conversion.

[roxaz]

i dont quite know how typemaps work, tried experimenting with them but without much success. looking at your changes so far i see some memory leaks (unless swig does free up those objects, but i doubt it). for example in %typemap(out) path&. sure heap allocation is needed? i think i had typemaps that compile with stack allocation. also new char[$1->size()] does not include null terminator. doesnt something like $result = $1->c_str() work?

next enum E_FILE_ARCHIVE_TYPE. Manually redefining that in interface works, but should it change in future manual updates to interface will be required. in my repository there is python script for handling that too. same script that modifies irrlicht headers to make swig like them. feel free to be lazy and use that py script too

and finally including headers one by one works, but like in previous case should new header be added it will require manual update of wrapper while with auto-includes new code would be wrapped automatically most of the time.