Loom Game Engine

[laomoi]

I tried Loom Game Engine this week, 

1. It is not free. But they can provide better service than haxe/nme, they will response me in 24 hours.And they have feature request voting, and they promise to release new versions every 1-2 weeks.

2. It use cocos2dx for rendering.

3.It use Loom-script(just like AS3 script) , and compile it into lua bytescode, execute it in lua virtual machine. So it is possible to updating code even after the game published to store.

I hope haxe/nme can support live code updating,   this is very very import in mobile game development. I need .hx can be compile to virtual machine bytecode.

Right now what I can do  is to use HScript which is pretty slow and not well supported in the working flow.

Please Please consider this feature in next version... 

[God Sony]

I think there is a way to  suit both these 2 engine/framework which is write  hxloom  converter ,mean that your haxe code can compiled NME or loom .

but some code is not easy to convert  such like   c# style  event+=fun,

and  I think hxcpp can use lua .dll to use runtime lua code .but I'm not sure.

--
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.
 
 

[Marcelo Serpa]

Why not a lua interpreter in NME + Haxe lua target?

-- 

Marcelo Serpa

Sent with Sparrow

[Philippe Elsass]

Why not Neko?

Philippe

[laomoi]

neko is good, what I need is a solution of using haxe code,convert it to vm code, can be updated and loaded ,executed whenever I need.

[ann cunzz]

Does C++ or Java for Android have live code updating? Why complicate the tool? Nme has quite good native performance, I wouldn't whant to risk  it.

[laomoi]

When you has published your game to over 50 platforms, unfortunately you find a critical bug, how to fix it in all clients in a short time?

I think lower performance and very flexible control of the code is acceptable.

And the vm embbed should be a option , you can turn it off if you want.

[Raincole Lai]

I agree. This is a very important feature if you target mobile platform. If you try Loom Engine out you will be surprised how fast the development process is.

[Marcelo Serpa]

Oh yeah, Neko. Embed the NekoVM in NME, sounds like a great idea!

--

[Baluta Cristian]

I would never trade performance for this, and i don't believe it would be faster neither for testings. compiling from xcode on the device is lightning fast, maybe if you chose NME is a problem.

--

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.
 
 

--
Băluță Cristian
http://ralcr.com
http://imagin.ro

[Marcelo Serpa]

> I would never trade performance for this

That's kind of bold. I think some performance loss in exchange for faster turnaround is acceptable, specially if you are independent. 

Anyways, we would only know the facts if NME is in fact embedded and we see some benchmarks. It would be a nice option to have for NME - mark some of the components as "native" and compile the rest (game logic?) as Neko byte code, which can be downloaded at runtime, if needed.

[Baluta Cristian]

nme already has 40% cpu in idle, so i don't think anything else will matter.

[Marcelo Serpa]

nme already has 40% cpu in idle, so i don't think anything else will matter.

Oh, I didn't now about it. Why's that? I haven't used NME on production yet.

- Marcelo

[laomoi]

Wow, what is eating the cpu? Rendering? 

[Philippe Elsass]

High CPU usage of an empty app says only one thing: the main loop runs too fast when it has nothing to do.

This is certainly an issue, but this aspect will fade away as you'll really use the CPU (note: rendering goes through the GPU, not the CPU).

Philippe

[laomoi]

Yep, you are right. 

[Ashish Ranjan]

actually the solution is haxe/lua , which will be a good target , but unfortunately damonsbane has not uploaded the latest anywhere

   but the best option is , if somebody writes a bytecode based VM "in haxe" itself.

neko will not be available in jvm (haxe /java) , haxe/js etc; but a VM written in haxe will be available in all the targets. Hscript will always be slow in absence of a bytecode VM

regards,

Ashish Ranjan

[Simon Richardson]

I would assume that hxparse could supersede hscript, as it seems hxparse is a lot more powerful (see test cases) in terms of parsing, putting a front end on that is a different story :)

https://github.com/Simn/hxparse/wiki/Writing-a-Lexer

Also consider looking at this: https://code.google.com/p/hxformat/source/browse/trunk/format/neko/VM.hx

Could be completely wrong though, Simn could update us on the idea behind it.

regards,

Ashish Ranjan

[Ashish Ranjan]

ya, may be hxparse be good for lexer.

if somebody re-writes nekoVM bytecode interpreter(not just its byteocde format reading using hxformat) in Haxe itself; then everything will be bestest of best. haha :-)  :-) 

Actually VM written in haxe itself is the Biggest missing piece in this haxe eco-system for many many   many people.

regards,
Ashish Ranjan

[Joshua Granick]

I think that porting Neko to work on mobile platforms would be great.

It's compatible with all the HXCPP binaries (such as NME and native extensions) and compiles instantly. It's deeply integrated with Haxe, and would be a flexible solution.

If you want runtime interpretation in your project, then I agree that another approach (Lua, Javascript, Hscript, runtime Neko interpreter) makes sense, but if you just want iteration for development, compiling Neko for a new platform might be a great way to go.

[laomoi]

Yea, So who can create this porting? It would be awesome!

[Raincole Lai]

I don't get it. Why does a iOS/Android neko VM help us to develop apps?

On Sunday, April 21, 2013 3:55:45 AM UTC+8, Joshua Granick wrote:

[Joshua Granick]

Neko compiles almost instantly, and could (theoretically) stream to a running application, allowing you to build and test almost instantly

[AS3Boyan]

>>When you has published your game to over 50 platforms, unfortunately you find a critical bug, how to fix it in all clients in a short time?

That is not a good choice, because it needs to be hosted somewhere! You need a server,  and I doubt Apple allow you to execute whatever you want and when you want! 

Better take a look at my project:

http://www.youtube.com/watch?v=reNmLB9lslQ

It's working for flash target, and I think you can create app/game, mostly using it, and then just polish for mobile devices. And you know in such development process, there are a lot of memory leaks(updating graphics in realtime). So release version should be clean and high performant!!! I don't know about that other engines, but in this case, we can just develop anything without performance loss.

Flash target builds fast, and I know how to make it even faster. Haxe can build flash in fraction of second even on low end pcs! if that is not a big project of course! Neko builds super fast too, maybe there is exist way to do this with neko.

You can develop core of game/design in flash(like I mentioned above), and then port to mobile using NME. Game is just restarts when you make changes. I think it should be enough for most projects!!!

Actually, you can do anything with this. You want to see your level in realtime, just run that in your code and you are good to go! Like this:

//addChild(MainMenu)

addChild(Level1_1)

And you can modify Level1_1 in almost realtime!

If you interested in my project, maybe I will release it. Just tell me. Please tell me if you think if there is a way to make it better.

пятница, 26 апреля 2013 г., 16:10:35 UTC+3 пользователь Joshua Granick написал:

[Samuel Batista]

This is pretty incredible! How did you achieve this?

[AS3Boyan]

Thank you! I'm glad you liked it!

Actually that was not too hard to make it. Just think about how this can be done for flash, and you will get the answer! I will explain how it works later!

But looks like, it's not super easy to use, because you will need to handle garbage collection yourself.

I will explain it later. That is actually easy. 

Maybe I will release this code under GPL(If you have other ideas, please let me know)... I think this tool should be free.

Haxe/NME tools should be free... I think. FlashDevelop is good, and it's free, so anybody can start AS3/Haxe/NME development in it, it's amazing! And this tool will be free.

I will create installer.

I will create tutorials\videos on how to install and use it. Actually this is not hard, it should be something like this:

1)Install program using installer

2)Install FlashDevelop Template(Double click on specied file and it should be installed easily). Currently it's working in FlashDevelop, but you can use any text editor you want, later I will provide instruction for it.

3)Start building process

4)Learn how to start and stop building process.

5)Learn how to dispose used resources for proper work of this tool(That is not too hard, but maybe I will simplify this process, by creating some simple framework, that will do this automatically for you). Anyway I think developers should know how to make this things.

This tool currently works only under Windows, but since it's written in Haxe it should be crossplatform, I will need to make some changes and test it.

[Samuel Batista]

Cool! Keep us posted :)

[yos arifin]

wow , nice job
we're entering live-coding era  ,this will be a very useful tool

[AS3Boyan]

I made a first version of HaxeBuilder. But maybe I should call it alpha, because I can't get it work properly with Stage3D frameworks(Starling). I think the problem is somehow connected with Stage3D. I think this can be fixed. Stage3D needs to be disposed or maybe I missing something. I remember that regular stage3D swf worked fine. Maybe I just missing something oblivious.

It needs testing anyway. Actuate lib working fine.

I created installer that should install this tool automatically(it should ask you about installing FlashDevelop templates). Please test.

https://github.com/as3boyan/HaxeBuilder

Licensed under GPL3

[Chris D]

Nice one As3Boyan, although its really cool its not live coding but probably the closest to it we can get without a vm etc.

I am not experienced with c++ but I wonder if SDL can support dynamic loading similar to flash does here, anyone know is there a hxcpp nme equivalent?

[dlots]

I don't know what you all are talking about. Apple doesn't allow dynamic loading of code, otherwise all of this can be accomplished with a reasonable implementation of any (Haxe) scripting language (there is a haxe scripting implementation on Google code by Nicolas) that can no less be conveniently bound to ORM instances with the correct and obvious architecture to accomplish this. I have contemplated doing this but it wouldn't accomplish anything because as specified Apple doesn't allow dynamic loading and would just get you banned eventually.

You're telling me Loom is claiming that you can update your game code after it is in the app store? That is bullshit because then you would have people creating app stores within the app store (a directory of VM games) including getting Actionscript to run in a VM and run all of the Flash games on the internet dynamically without any alleged oversight by Apple or other conduct along those lines:

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework.

On Friday, April 12, 2013 11:26:41 PM UTC-4, laomoi wrote:

I tried Loom Game Engine this week, 

1. It is not free. But they can provide better service than haxe/nme, they will response me in 24 hours.And they have feature request voting, and they promise to release new versions every 1-2 weeks.

2. It use cocos2dx for rendering.

3.It use Loom-script(just like AS3 script) , and compile it into lua bytescode, execute it in lua virtual machine. So it is possible to updating code even after the game published to store.

I hope haxe/nme can support live code updating,   this is very very import in mobile game development. I need .hx can be compile to virtual machine bytecode.

Right now what I can do  is to use HScript which is pretty slow and not well supported in the working flow.

Please Please consider this feature in next version... 

[dlots]

If you're looking for a more convenient building procedure, you can accomplish something that is quite fluid with regards to building for iOS, Android and Flash that wouldn't take more than 3000 lines of code, so get to it ;)

I fail to see why any reasonable developer would cite running production game code in a VM as opposed to native as a requirement or a disability, especially considering you can test easily against neko on Windows/Linux. I fail to see how haxe's current progress is inferior at this moment in time even if it doesn't have the low priority and frankly, pointless feature of running production code in a (non-typed I'm sure lol) VM for some unknown reason on (CPU constrained) mobile platforms... I can't imagine a lot of reasonable people are interested in this.

What is an actual issue and is the direct opposite of this questionable VM idea is the fact that generated hxcpp/java generics typing is not optimal.

You're more than welcome to want to have a VM to run your mobile code in... but I have no idea why anyone would want that for production code when you can potentially have a delicious high performance C++ implementation from your haxe source, which is the promise of Haxe.

I'm not sure the type of live coding you're talking about is applicable to NME as NME is a scene graph not a game engine. Take a look at Unreal Engine's implementation. You need an actual logic loop and a more constrained scenario than what NME is doing for live coding to be reasonable, ie, I'm sure you can auto recompile and relaunch your application, but Unreal Engine's live coding is a little different than that and is more convenient because it works within the context of what it actually running in the logic loop.

On that note, with regards to a logic loop, I can tell you that the way the current logic loops are implemented in Flixel and other "Flash" engines is retarded because they are not deterministic and bound to the renderer.

[dlots]

Oh I think you understand what you want. I think you just want a scripting language for your game. You can accomplish this with a thought-out architecture with the Haxe script implementation on Google code. Writing game engine code in a scripting language is a questionable idea IMO. Take a look at how game engines are usually done. You're more than welcome to write your game's logic with scripts but it's recommended to separate your game engine and your game logic in a well thought-out way.

[Zjnue Brzavi]

Hi,

This discussion made me remember Orbit.

I've not seen any mention of it here, so doing just that in case it is of interest to anyone.

http://www.profound7.com/
http://www.profound7.com/blog/orbit/introducing-orbit-the-awesome-mix-of-lisp-lua-and-javascript/
https://github.com/profound7/Orbit

Zjnue

[curious guy]

WOW. This "Orbit" is a real hidden treasure. 

Though by looking on its github source code, it seems it is not alive (and not ported to haxe3) since a year.

But it still seems to be good. 

One thing best though with hscript is that :  the glue code (FFI) to expose haxe class as hscript is almost not required; what about Orbit?

probably we need a VM written in 100% haxe, to which different scripting flavours can compile. This can be probably be nekoVM itself rewritten in haxe. So almost all scripting dialects can compile to it. So that scripting VM will be available in all the haxe targets (current or future), and people can implement their own lisp like syntax (Orbit) and haxe like syntax (hscript) , etc etc.

[AS3Boyan]

Thank you, Chris!

That's a kinda live reloading, you right. Using Vm is nice option(or maybe hscript), but to make it work, we will need to do many things, including converting code to be ready for production(because we need high performance apps/games).

Live coding is not easy to implement. Software will need to detect changes(like new line or modified line) and sent them to VM(or interpret using hscript).