External Library Integration inside Mojo

Monkey Forums/Monkey Programming/External Library Integration inside Mojo

Tibit(Posted 2012) [#1]
We have not found a way to integrate certain libraries into Monkey on iOS (as a specific example) that require access to this that are inside mojo.

For example some libraries require that one implements an Interface on the ViewController (iOS). So the way we solved this was to manually edit the translated code. Which works, but it is crazy since all changes are overwritten every time and the code cannot be reused - so it needs to be copied or rewritten every compile (on that target).

Is there any possibility to work around this? It really hampers our ability to use external libraries.

We are using external libraries. Such as Chartboost (which unfortunately requires access to the ViewController) and I assume it would benifit everyone if there was a way we could create a module or so for this, but since it requires changing the translated code, that is not possible.

This is a big time-obstacle in implementing 3rd party things.

Please any help appreciated!


gekkonier(Posted 2012) [#2]
Have you considered to create an own build chain?
I think with a good scripting language (just think about ruby, especially rake) it should be easy to first build with the monkey tools and then alter the source automatically?


Tibit(Posted 2012) [#3]
Using an a simple external tool that we build you mean?


gekkonier(Posted 2012) [#4]
If it's a repetitive task after building in monkey to adjust the resulting files in exact the same way every time, then it looks like an ideal task for a scripting language like ruby or perl.


jpoag(Posted 2012) [#5]
You could edit the target source files.

monkey/targets/ios/main.h(mm)

Create a patch file from your edits and the original, then whenever you update monkey, patch the target source. Then every build will generate the modified source.


Tibit(Posted 2012) [#6]
I'm not sure that would work so well for other people using our framework/engine. One benefit of having the engine in a module is so that it can be used in multiple projects on multiple computers using multiple monkey installations.

I feel like this is a "glitch" in monkey.

If there was only a way to add these kinds of libraries in Monkey code it would not be a small feature thing, it would be a huge benefit! :)

Not necessarily because everyone will use it, but because everyone writing a more complex module could share it with everyone else - meaning that many would benefit from this.

What I want is both as a module user and module creator to be able to add a module, and that module can (in what ever way) modify the end project automatically so that more complex features "just work" out of the box.


Gerry Quinn(Posted 2012) [#7]
This comes up all the time, and it's not an easy issue. Hacking mojo works okay if you just want to get at something simple for your own code, though it's inelegant. Your requirement for third party access is more complicated.

The problem is: how can mojo become infinitely flexible and still exist as a library at all? There are always going to be some limits.

I would like for example if mojo had a GetBitmap() function that would return a reference to the drawing surface in each target. That might be workable (I'm not sure). But certainly there must be things that you would like to access that only exist in one target, like maybe your ViewController whatever it is.

Maybe there could be something like GetObjectReference( objectType ) that returns a specific object (objectType is a const or a string) that might or might not exist in every target. If it doesn't exist in the current target it would return null. You would have to cast the returned object to whatever it was supposed to be.

I think we need some brainstorming on how mojo could practically be made more extensible.


Tibit(Posted 2012) [#8]
Good points.

Need more brainstorming, both to uncover what the real problem to be solved is and how to solve it.

Yeah I almost forgot mojo is "only" a module. But that is true.

The awesome thing would be if a change could be made so that any module could be more flexible in this regard, and mojo could implement that to solve this.

It feels like it is when inheritance comes into the mix (on the target platform) that things gets more or less annoying. However we cannot do much about the design of the platform target.

Any suggestions on what exactly mojo or monkey could do? some kind of Translation-Meta-Hooks maybe?


Kalakian(Posted 2012) [#9]
Have you considered not using Mojo for iOS? That may not be an option for you, but thought I'd throw the idea out there.

Let me explain...

I'm still quite a newbie to Monkey, but I've got some experience with writing XNA programs. This has been a bit problematic for me as I find that I'm giving up some features I was used to with XNA, in exchange for the cross-platform functionality Monkey provides. Yes, I want my cake and to eat it as well ;)

After spending a bit of time doing some tests and examining the exported XNA code, I've come to the realisation that Mojo is my biggest hurdle (for XNA, not altogether). My potential solution is to develop a wrapper around the Mojo functionality, but only for non-XNA targets (using the preprocessor). For the XNA target, I will define the same API as the Mojo wrapper but use External declarations so the "wrapper" is actually defined in native XNA code.

This, in theory, will allow me to continue using Mojo for platforms I don't have as much knowledge of, while gaining access to the specific features I want from XNA.

Perhaps this would work for your iOS target? Like I said, it may not suit what you want to do, but no harm in suggesting it just in case.


pantson(Posted 2012) [#10]
I've been looking at the auto building of the external files for android.
I see that trans would need editing to merge or create xml files and to copy the relevant jars to the libs folder.
Maybe this would be the same for other targets.
Its also something I will have a look at when I finish the current game.


Tibit(Posted 2012) [#11]
I see that trans would need editing to merge or create xml files and to copy the relevant jars to the libs folder.
Yes. It would be enough if trans was change only with the option to output data that an IDE could hook onto.

Have you considered not using Mojo for iOS?

True I do want to eat the cake and still save it for later. I agree mojo is the biggest hurdle, and maybe it is simple enough to just "wrap" things up. That would make little sense in terms of adding External libraries and such, however it is something I have considered for future projects so that I can get better performance (and some features) out of each platform.

However writing a mojo from scratch is probably easier said than done. Mark is quite skilled if I'd say so myself, and even tough Monkey & mojo isn't perfect yet, it is pretty good :) I mean writing a wrapper for one target is simple, writing it for 7, not so much.

I'm happy to write external tools to fix things like this. If only trans had more hooks/options for such tools.

Its also something I will have a look at when I finish the current game.
Awesome! Keep me updated! :)


marksibly(Posted 2012) [#12]
Hi,

> For example some libraries require that one implements an Interface on the ViewController (iOS).

I think the best way to deal with things like gamecenter/ads/etc that want to mess with the ViewController is to create a custom target.

This is a little hard to do right now, but could be made easier. One approach I can think of would be to provide support for something like TARGET=... in target CONFIG.TXT files. Trans could then scan for this in all target/ subdirs, allowing you to create 'ios_gamecenter' style targets that can be easily redistributed.

Trying to 'modularize' ViewController would I think cause more hassles than it'd solve. In fact, I think in general any app related 'singleton' objects like ViewController (and AppDelegate, MonkeyView in Android, more?) are probably better off in the target code, not Mojo, as such objects are intimately bound to the target (and each other) in fiddly, low level ways.

Note that I am NOT saying here that Monkey shouldn't support 'libraries/headers etc in modules' or anything like that - it should (and will eventually), but I think this stuff is a special case.

Another simple-but-flexible tweak for trans I've been thinking about would be for trans to check for a trans.exe inside each target and to use that instead of itself to build! A bit nasty, but it'd at least allow for custom translators etc to be redistributed without the need for an interpreter yet.

> I would like for example if mojo had a GetBitmap() function that would return a reference to the drawing surface in each target.

I think this is a different problem - ie: how do you extend Mojo?

The current situation is that Mojo isn't really extensible, and if you want to use it on a native level you need to hack it! But the alternative (ie: provide a nice API for native Mojo so it can be extended cleanly) kind of involves writing 5+ APIs - not gonna happen sorry.

But there are probably some additions that could help people at least mix Mojo graphics with 3rd party native code - something like PushState/PopState perhaps? This would allow you to write native graphics code that didn't have to hack Mojo just to draw something.

Not sure about GetBitmap() - it can mean very different things on different targets and at the moment I'd probably be more comfortable with people just Mojo-hacking.


Kalakian(Posted 2012) [#13]
... allowing you to create 'ios_gamecenter' style targets that can be easily redistributed.


Are you ok then with us taking an existing target, hacking the code a bit, and redistributing it as a new target? Not saying that's my plan right now, but it's something to consider rather than by-passing mojo altogether.


marksibly(Posted 2012) [#14]
Hi,

> Are you ok then with us taking an existing target, hacking the code a bit, and redistributing it as a new target?

Yes, that's fine - Mojo is the only closed/proprietary part of Monkey.


Difference(Posted 2012) [#15]
But there are probably some additions that could help people at least mix Mojo graphics with 3rd party native code - something like PushState/PopState perhaps? This would allow you to write native graphics code that didn't have to hack Mojo just to draw something.


BIG YES Please! :-)

This is number one on my Monkey wishlist.
I'm currently hacking my drawing routines into every new version, and it slows updating to new versions down.


Skn3(Posted 2012) [#16]
Definitely please do open up a channel to the mojo graphics innards! I have been dancing around the closed bmax 2d commands for months but there have been times when I am forced to modify the core modules. Monkey needs to lose some of this restriction, otherwise it's a massive pain in the bum!

At least provide api functions to hook into the protected fields. GetGraphicsContext() GetImageContext(image) or something like that.


dmaz(Posted 2012) [#17]
At least provide api functions to hook into the protected fields. GetGraphicsContext() GetImageContext(image) or something like that.

+1