Native Extensions


#101

Thanks @britzl and @AGulev,

These are good starting points.


#102

Great job!:grinning: So how to identify windows, DM_PLATFORM_WINDOWS?


#103

Yes, exactly like that.


#104

Did somebody try to make iCloud native extension?


#105

Does here any way to use autocomplete for c++ code from native extensions?


#106

You could try using some clang-based autocompletion engine. clang-autocomplete works great for Atom or YouCompleteMe for Vim. They’re pretty easy to set up for any given project. You might also need the Defold SDK header files. Not sure if those are public. You’ll have to check


#107

What about header for Defold SDK, @britzl ?


#108

There was actually some legal technicality that prevented us from sharing the headers (essentially a part of our closed source engine). I’m not sure if this is resolved yet @Mathias_Westerdahl?

It should be fairly trivial to create the headers manually though…


#109

Correct, and it’s unfortunately not resolved yet.
I hope that we can make the sdk more accessible in the future, as a part of being able to build native extensions on a local server (ETA unknown on that)


#110

Another example,

If you’re looking for basic functionalities or starting codes of Apple Game Center Extension,
checkout :

Some screenshots for iOS :

  • Login :

https://s18.postimg.org/ocrxf7it1/image.png

  • Login In progress :

https://s18.postimg.org/hq9uzrqid/image.png

  • Logged in :

https://s18.postimg.org/j2mynwyk5/image.png

  • Show a leaderboard :

https://s18.postimg.org/f7jklcfed/image.png

  • Show leaderboards :

https://s18.postimg.org/505mmoik5/image.png

  • Show achievements:

https://s18.postimg.org/n48n7bg8l/image.png


#111

We have a GameAnalytics native extension that works on Android, iOS, Windows, Mac and HTML5 check it out here if you interested in using it or just want to use as reference to make a native extension yourself on one of these platforms:


#112

Any news about DEF-2732 (possibility to use dynamic libraries)?
As I understand it is stopper to make fmod native extension…


#113

No news as far as I know. I believe Linux support will be next and then improvements after that.


#114

Linux taking longer than expected?


#115

No, I don’t think so, but other things came up and then also summer vacations for the team. @Mathias_Westerdahl knows more.


#116

I’m finally back from vacation and a cold, and I’ll continue with the linux support now :slight_smile:


#117

Here’s a tiny update on what’s currently going on with the Linux support for Native Extensions.

In an effort to make our build process easier to maintain, we’re currently updating out build servers to use the same Docker container as the extension server. This is an Ubuntu 16.04 version, and for that to work, we also needed to rebuild and/or update many of the libraries. E.g. updating to LuaJIT-2.0.5 to add support for OSX 64 bit and Windows is a good example.

At some point, we all thought that the Linux platform would be the easiest, but now it has proven to take as long as the android support. doh

We’ve made the decision to cut support for 32 bit OSX builds, since the all our supported macOS versions are already 64 bit, and macOS is moving towards 64-bit-only support in the app store.

Along those lines, we’ve decided to stop supporting 32 bit linux builds too, since the apparent user base is really really low. The Editor2 for instance is already only shipping on Linux 64.

There are still a few loose ends to finish up, but my current estimate is that Linux support for native extensions is 1 or 2 sprints away.


#118

IIRC Defold have 2 weeks sprints so: 2 or 4 weeks


#119

What is the best way to close game from the c++ code? something like msg.post("@system:", “exit”, {code = 0}) but in NE c++
UPD: I am use ExitProcess(0); on Windows, thanks @Sublustris


#120

Today we had an exploration day, which means we can try out various ideas that could be beneficial to the engine, but aren’t necessarily scheduled soon (or at all). (Other companies call it Hack Day etc)

What I tried today was to tie together a test branch we had that @ChristianM had prepared, where we have an extra physics library: physics_null, and the Native Extensions’ App Manifest.

The app manifest lets you modify what libs/symbols/jars etc that should or shouldn’t get linked into the engine.
After some small modifications, I got it to work nicely. I still have a few things to clean up (or think through), but this functionality should arrive in a sprint or two :slight_smile:

My example game.appmanifest:

platforms:
    # Null Physics
    common:
        context:
            excludeLibs: ["BulletDynamics", "BulletCollision", "LinearMath", "Box2D", "physics"]
            libs: ["physics_null"]

And some before/after results on x86_64-osx:

mawe@physics_null (master) $ ls -la dmengine*
-rwxr--r--  1 mawe  staff  4463180 Oct 20 15:58 dmengine_no_physics
-rwxr--r--  1 mawe  staff  3375996 Oct 20 15:58 dmengine_no_physics_stripped
-rwxr--r--  1 mawe  staff  5619372 Oct 20 15:59 dmengine_physics
-rwxr--r--  1 mawe  staff  4111380 Oct 20 16:00 dmengine_physics_stripped

4111380 - 3375996 = 735384 bytes saved


Teaser Fridays and Roadmap talks