Is it possible to create this feature in nme: Lua Binding

[laomoi]

It is a big trouble when you want to fix bug/add new functions after your game has been published. 

May be you can popup a version update dialog to make game upgrades, but  it needs the user to download the whole game again.

I see some cross-platform framework like cocos2d-x supports lua binding, so you can write all your game logic in Lua files, creating display list and do io operations in these lua files, executing them in runtime. When your game needs updating , your game can automatically download the new lua files and the assets if needed. User never need to download your whole game again.  And you donot need to publish your game to the store again.

I hope haxe/nme can support this amazing feature,  binding lua or binding  Javascript. This is a very important feature.

[Raincole Lai]

+1 for Lua, -1 for JavaScript. And doesn't NME has its own mailing list? (http://haxe.org/forum/thread/3611)

[God Sony]

+1 binding  hx in runtime

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[laomoi]

Another topic about this :   https://groups.google.com/forum/#!topic/haxelang/NpPTDRw8LLU 

I hope the author of Haxe can consider this feature in the road map.

[Juraj Kirchheim]

I'm puzzled. With the workflow you describe, would it not be easier to just use Corona? 

Or what exactly is it that you want to write in Haxe?

--

[laomoi]

I can use haxe to write the basic functions(such as rendering,  native api calling) or performance-sensitive functions  which are difficult to be implement in Lua/Javascript.

I don't have experience on  Corona.  May be I can have a try. I just hope some one have the same requirements  and can create some extensions of haxe to enable this feature, since I am new in this field. :(

[Raincole Lai]

Corona is really a good tool, but there are still something Haxe can do but it cant. For example you can't develop flash/desktop thing with Corona. Of course you can't use Haxe, which I think of as a very advanced language. Moreover, some of us just don't like to depend on a non-open source toolchain. 

On Saturday, March 30, 2013 6:10:28 PM UTC+8, back2dos wrote:

[Cauê Waneck]

Now that neko has changed its license, I think embedding neko would be a more sensible approach. Neko VM is very small, runs quite fast, and one could still write in haxe.

2013/3/30 Raincole Lai <rain...@gmail.com>

[BP]

and even though it's not lua, you can use hscript in Haxe, and it works in both desktop and web platforms (flash too!)

https://code.google.com/p/hscript/

and Lua stuff probably wouldn't work in Flash unless it was built in Haxe itself!

[laomoi]

Sounds cool! I will take a look o hscript

[laomoi]

HScript is created by the haxe author Ncannasse?

On Saturday, March 30, 2013 10:41:53 PM UTC+8, BP wrote:

[BP]

I think... yeah... he's the main contributor from what I see.... and if you set "allowTypes" on the parser, then it's really close to haxe.... but it ignores types.... definitely try it out...

[laomoi]

Ncannasse says HScript is not very fast, so I make a small test, haxe code like this:

var s = 0;

for (i in 0...100000) {

  s = s + i * (i + 1);

}

it costs almost 0 ms when use hxcpp compiling and run it on android target, but if I run it as HScript on android, it costs almost 900 ms.

It is pretty slow :(

I tested the code using air+android, it costed 30 ms.

[Ashish Ranjan]

      i would have loved to see support of classes, enums, typedefs in hscript; esp the classes.      O8-)

Ashish

[BP]

Well I think one of the best approaches with hscript is to code parts of your app in it, and then actually convert them to haxe, which if done correctly, should happen very easily.... so more of a composition based approach than a class hiearchy approach.... but I agree, it'd be nice if it was faster ;-)

[Hugh]

Hi,

I have put some experimental stuff in have v3 for compiling to dynamic libraries. It goes like this:

1. compile your "engine", plus any libraries (eg, physics) into an app, but give the it the "-D dll_export" define.  This generates an "external" directory for you that you use in phase 2.

2. Compile the "app specific" stuff into a dll by using the "-D dll_import=import_dir", and a class path pointing to your previously generated externs.  The import_dir is to give the dll something to link against - eg, the link.lib generated by the windows compiler.

Phase 2 creates a dll that you can use from within your app like this:

  var name = dir + "/assets/" + nme.installer.Assets.getResourceName("Client.ios.dylib");
untyped __global__.__hxcpp_run_dll(name,"__main__");

The  hxcpp_run_dl code can run from a file on disk, so then it is up to some library code to get this file - eg, as a resource (shown here) but there is no reason why you could not download it from the internet or upload it over a socket.

Because the dll can be run at any time, you could have a full nme loader screen with options and graphics etc, before you run the dll, where you could select the dll version etc.

The dll only contains the app files that you have not put into the loader/library, so it is very fast and very small. It is true native and runs at 100% native speed.

Similarly, the "dynamic update" code of spaceport.io could "easily" be done with library code:

nme.Asset.getBitmap("asdasda")

becomes:
 mylib.DynamicAsset.getBitmap("asdasda", onChangeCallback = null)

And you can establish a socket connection and transfer data etc (the hxcpp debug socket does something like this).  So you could also transfer the dll and maybe mix in the debugger code for icing on the cake.

This also gives someone the opportunity to generate a loader app and externs, and create host that could be used by many developers.

Since the app code does not need to rebuild the hxcpp runtime, it may be possible to get away with a smaller subset of compiler files on the developers disk.  Eg, you do not need to link against any ios runtime files (since you link against the hxcpp loader app, which links against them) so cross-compiling may be easier.

The code is still experimental, but it works on all targets with a bit of love.  You will not be able to sell an ios app like this on the app store but the good thing about this is that you can just recompile exactly the same code into an app once you are satisfied.

So I can offer some assistance in getting the compiler features going, but the other stuff (eg, dynamic update) is simply haxe code that could be written by anyone and does not need to be part of the NME framework.

Just write this function using a socket:

 mylib.DynamicAsset.getBitmap("asdasda", onChangeCallback = null)

and you have done dynamic asset updating.  Once you have this, it can be extended to dlls.

I'm also thinking it may be possible to use these externs and combine them with a VM already supported by haxe (v8/neko/as3) to have a hybrid version where most stuff in done in hxcpp, and some stuff can be done in vm for a speed/update tradeoff, but there is still some work to be done meshing the hxcpp runtime with the vm gc etc.

Hugh

[laomoi]

Awwwwwwwwwesome! I am getting exciting!  Hugh.  Could you write a example to show how it works when targeting IOS and android ? I think most NME users can't wait for it!

[Dion Whitehead Amago]

I have a dynamic asset reloader/server at 

https://github.com/dionjwa/flambes

ATM it's set up for the flambe engine, and its a WIP. The server can work with any client with a bit of adjustment.