Not Using C++ to use C++ 3rd party stuff

Community Forums/Monkey Talk/Not Using C++ to use C++ 3rd party stuff

H&K(Posted 2011) [#1]
Nearly all of this might be wrong, so don’t worry about attaching the foundation of the question.

For a moment lets look at Bmax and a C++ dll/library or whatever (Someone telling me exactly would be helpful), lets use irrlicht.

Now If something new comes out in the IRR range, (irrmagicsprites or whatever), ATM I need to wait for Gman to do some magic on the C++ side (or c), and then write a load of importers/defines or whatever. (Again although this isn’t the question Id love it if someone could explain what he's doing, and what you can and cannot do it with etc.). So I’m basicly at the mercy of Gmans generosity to keep updating as and when.
Because in all honesty if I understood C++ I wouldn’t have moved back to Basic from it in the first place.

So... Monkey,

If I’ve understood this right, monkey will produce C++ or C# code, which is then compiled by the relevant compiler for that language. So in theory the stuff that Gman does in C++ to get Irrlicht to work in Bmax I could write that stuff in monkey and then it would write it in c++, and then I could use it in Bmax.

Now if I was using Monkey, Id probably be better to drop Bmax, So again the stuff that Gman does in C++ to get Irrlicht to work in Bmax I could write that stuff in monkey and then it would write it in c++, and then I could use it in Monkey.

Does this mean that I can get a 3rd party engine (Again lets say irrlicht), and use it in Monkey without having to do anything in C++? That is whatever I did need to do in C++ I could just get monkey to do?
If so, what do I need this third party engine to provide? A header file?


Brucey(Posted 2011) [#2]
You will still need glue to connect the Monkey generated code with the library.
Or wait until someone ports the whole of the library into native Monkey - this appears to be the favoured approach, since the key is the ability to write you game to run on all the supported platforms.


H&K(Posted 2011) [#3]
since the key is the ability to write you game to run on all the supported platforms.
I don't think that's the key. I think its a USP for Monkey, but I have Bmax and never do anything for the Mac or that other OS. And I have no intention of making stuff for iPhones

If this is the standard of Monkey stuff, that it needs to run on all the platforms, well I consider that this will hinder development on the better faster platforms.

You will still need glue to connect the Monkey generated code with the library.
And can this glue be written in monkey?
If the library is in C++, and the "Glue" is in C++, and Monkey can write c++, then can Monkey write this glue?


Brucey(Posted 2011) [#4]
Glue is dependent on the underlying structure of the library. In general, all libraries are not created equal, and therefore glue must adapt to fit a particular library.
Also, Monkey has no concept of pointers, making library-native callbacks a problem - more special glue is required to wrap those.
But yes, once you have the glue, the resulting Monkey app that you write to use the library will be compiled in native C++, with the glue linking them together.