If I remember correctly, you should be able to put the .framework
folders inside your lib/ios/
folder.
FYI, @Andreas_Tadic and @sicher have now added the SDK documentation to the documentation page under the category Defold SDK
Yay, been needing this. What happened to dmScript::Get/SetInstance? I’ve written an AdMob extension, and it almost works (I can show interstitials,) but any time I call a Defold fun from within a Lua callback (called from native extension code,) I get a crash. So, looking at @britzl’s Gyrobomber example made me think that the secret sauce I was missing was Get/SetInstance. Should I be able to call Defold funs from a Lua callback (via lua_call) without any special setting up of the context? The callback itself is actually called and I can do other things in it, I only crash when I call Defold funs from it.
Hi @nox!
Happy to see you’ve made such progress!
Yes, as you could tell, we hadn’t include some functions in the sdk yet, we’ll be sure to add them in the next release.
In the mean time, you should be able to forward declare the missing functions at the top of your .cpp-file, and you should be good to go. Let me know how it goes!
NOTE Beware that this code is subject to change until it’s released in the stable release
namespace dmScript
{
/**
* Retrieve current instance from the global table and place it on the top of the stack, only valid when set.
* @param lua state
*/
void GetInstance(lua_State* L);
/**
* Set the value on the top of the stack as the instance into the global table and pops it from the stack.
* @param lua state
*/
void SetInstance(lua_State* L);
/**
* Check if the instance in the lua state is valid. The instance is assumed to have been previously set by SetInstance.
* @param lua state
* @return whether the instance is valid
*/
bool IsInstanceValid(lua_State* L);
/**
* Retrieve the main thread lua state from any lua state (main thread or coroutine).
* @param lua state
* @return the main thread lua state
*/
lua_State* GetMainThread(lua_State* L);
}
Hi everyone!
As promised, we’ve cleaned up and shared two native extension examples on github.
You can find them here:
Camera
Video Player
Hopefully, we can share more examples soon.
NOTE:
As mentioned in their readme’s, you should view these as (working) examples. Although we aim to keep them working and show some good practices on how to do things with Lua + extensions, at this point we will maintain them as just that, examples.
HI there!
Heres another small update:
We are continuing our work on the Android support, which is well underway, but still have some way to go before it’s considered fully working.
Also, we are working on a Lua api for our new “buffers”. The native extensions communicate with the engine via Lua, and with the help of our new buffers, they can pass large memory chunks between each other without doing memory duplication. With this Lua api, it will be possible to create such buffers directly from Lua, without the need of creating a native extension. Here is an example, we create a buffer, render a bunch of particles (simple plots) to that buffer, and set the texture on a sprite:
Ohhhh lovely. Does it mean we can also pass audio buffers and do chiptunes on the fly?
Not yet, but that’s one of our goals
the ultimate chiptune engine! I am sold
Tiny teaser for AdMob support for Android:
We are continuing our effort to add Android support to Native Extensions, and today we managed to get our example app running. It’s a big milestone in that it tells us a lot about what we need to do in order to make this a usable feature for the users.
Cheers!
I know the updates are few and far between, and I can only apologise and I hope to better our update rate
The good news is that we’ve made good progress on the android support and if all goes well, we’ll have full android support in our next release (C/C++, Jar files, Java, resources)
Today we were able to build our AdMob example properly (I.e. No hacks or workarounds) through the editor for Android, and now we’ll make our admob example more presentable so that you can try it out soon (iOS + Android) for yourselves
As a a Friday teaser, please enjoy a repost of the last image ^^
Yay! Great news. How about AAR files? Many SDKs now provide AAR instead of JAR.
And have you incorporated multidex support already or is it planned for later?
The AAR support is in the back log, and I’ll create a ticket for the multidex support.
I believe both will be resolved after we’ve added support for all platforms.
I can’t find all defines for NE (for ex. DM_PLATFORM_OSX and etc)
Is it possible to add list to the documentation? It would be great!
Thanks!
Yes, there are quite a few things we need to setup better documentation for, and all the available flags, etc is definitely amongst them. I’m going to start rolling that ball at least.
In the meantime, the current platform defines are:
DM_PLATFORM_OSX
DM_PLATFORM_IOS
DM_PLATFORM_ANDROID
(I won’t add the others yet, since they haven’t passed review yet)
So, with the release of 1.2.103, we’ve added full support for Android builds with java, jar files and resource files. I will add a simple example of this on our github today to get you going.
Until then (for those eager to jump on the boat), you can try:
- Add .java files to your
myextension/src/
folder - Add .jar files to your
myextension/lib/armv7-android
folder - Add JNI calls to java in your cpp source, to call your java/jar code
- Add resource files to your
myextension/res/android/res
folder (for resources to be put in the R.java)
I’ve added a test project to demonstrate the full Android support here: https://github.com/defold/extension-android
It’s a simple example that demonstrates the use of Android resources, .jar files, .java files and JNI and some native functionality (vibration).
HI again!
This time I just wanted to let you know that we’ve started with the HTML5 support for native extensions, and we have managed to get the server to compile and link the engine. A good start. Next up is compiling the actual extensions, which should be a relatively easy task. And next after that, we’ll look into adding support for adding “.js” files into the /lib folder.
I know some of you are curious about the potential WebAssembly support, and although we won’t add it right away (we’re still on Emscripten 1.35), it doesn’t seem like it’s going to be a very big task to support it once it goes into the next Emscripten stable version.
Sounds great. Just to clarify, if you know, will I be able to compile the OpenAL extension or will I have to rewrite it in JavaScript?
It seems like Emscripten supports OpenAL out of the box: https://github.com/kripken/emscripten/issues/666