Target System

Monkey Forums/Monkey Programming/Target System

bruZard(Posted 2012) [#1]
Is there any chance to get a rethink of the current target system? I mean a system like "plugins". I think about a Ogre3D target because i work (again) on the B+/B3D/BMax engine, but i can't do that for Monkey. Because Monkey doesn't support external libs. We have Ogre3D for Windows, Linux, Mac, iOS and partially for Android ... i think it would be a great thing to have Ogre for Monkey, as a target or (better) as a module.


Armitage1982(Posted 2012) [#2]
I wanted to know if Monkey could use external libraries and I got an answer from Ziggy on this thread : http://www.monkeycoder.co.nz/Community/posts.php?topic=2735

I want to try this today with a simple lib and see if it's actually doable to use libraries like LibXML, Box2D & CEgui. But I guess it's not easy or else everybody here would already use original libs rather than porting them.

If I'm not using Monkey right now it's simply because of that, nothing more.
I'm not sure if the idea with monkey is still making games or being able to port small projects on several system. Most will probably answer "both" but I see very few tools available for making modern games.

Now it's just my 2 cents ;)


bruZard(Posted 2012) [#3]
I can't use Ogre3D in this way ... Monkey is cool for small indie projects, sure ... but i think that small projects can benefit from big engines like Ogre3D.


muddy_shoes(Posted 2012) [#4]
But I guess it's not easy or else everybody here would already use original libs rather than porting them.


Err... that's really not why I ported box2d to Monkey rather than creating a wrapper/interface layer to target native versions.

The advantage of porting to Monkey is that you know (as long as Monkey does its thing) that the module will then work on all targets and all future targets without additional effort. That's the main selling point of cross-platform languages after all.

While I'm sure there would have been problems to deal with, I doubt that wrapping the original box2d would have been more difficult than porting. I imagine the opposite in fact. What would cost a lot of effort would be to bring all the "native" port interfaces into line and keep them that way over time. Unless you do that, you're stuck with a module that only works on a sub-set of targets and that's hardly worth much in the Monkey world.


Armitage1982(Posted 2012) [#5]
I can't use Ogre3D in this way

Can you tell me why you can't? Because I will probably face the same problems of yours so...

Unless you do that, you're stuck with a module that only works on a sub-set of targets and that's hardly worth much in the Monkey world.


I'm good with that :) Why not considering this as another great features of Monkey. After all I already know that library like libXML won't work under iOS or Android.

I just want to port my game engine to Monkey for using it under Windows, Mac and Linux with up-to-date external libraries and benefit from the Monkey Language improvements.

But for instance the documentation is not very helpful.


muddy_shoes(Posted 2012) [#6]
I imagine that it's a case of it being rather difficult to provide documentation that explains how to use every single native target language and development environment. The provided modules and targets act as reasonable examples of what you need to do though.

I can't say that I see a great deal of sense in pursuing Monkey if you are only interested in Win/Mac/Linux desktop targets. It's really not focused on those.


Armitage1982(Posted 2012) [#7]
Well... Maybe you right. Specially when I have a look on the I/O and the general framework.

But currently most of the targets (GLFW, STDCPP, XNA, Flash, Html5) does not focus on Mobile use and only a few of these will give you interesting performances for games.

I learn with BlitzMax and I like to work this way. So until a more game oriented solution exist (like Unity3D or XNA Game Studio) supporting the main 3 desktop platforms, I need to learn how to get the most of my current tools.

I also want to free myself from the begging of library port.


AdamRedwoods(Posted 2012) [#8]
I ported minib3d because 1. to get many platforms and 2. it was difficult to plug into the existing minib3d c++ code.

From what I've experienced, hooking up to external libraries involves crossing the GC'd to non-GC'd realm, so requires some thought. The trick is to declare your external functions with "Extern Class Extends Null" to keep the GC from collecting, but then you have to manually free memory. **BUT** since monkey has no OnExit() in the App Class, how are we to do this? I must say, though, there are tricks to allow monkey to keep and manage the c++ object itself, but this would be a different topic.

Also, trans.exe or the project files would require some adjustments to allow linking to external libs, for both MacOS and PC (which I can do with mingw easily).

I may try to investigate this further (wxMonkey?), but for now it's not so cut and dry.


ziggy(Posted 2012) [#9]
Maybe making Trans traslate to Java would make it easier to be "plugineable" in all platforms. It shoult not take a lot of time to port the os module to Java. Just my two cents.