Yeah, that's fair. I'd update the summary if I knew how; I thought that was implied as the last mile of any console solution is bound by proprietary terms, but in retrospect I see how it's confusing.
That's actually a concern of ours and we've designed the architecture around it to leave as much code as possible open source.
To be clear we are NOT creating a new, non-open-source fork. We're using the existing public stack of OpenFL and Lime you can find today. However, as you can read in the article, we're building console-specific "batteries" that slot into the very last mile of the console stack as a separable library that can be safely distributed under the terms of console NDA's, without putting any burden on the existing public codebase.
What you're basically asking for is the underlying Lime layer which is a part of this solution. The "OpenFL" part -- the Flash API implementation, is a convenience layer that would, yes, make it possible to port flash games to consoles, but the underlying Lime layer is pretty close to the metal and does as little as possible while unifying things like asset management and providing direct access to a consistent rendering API.
This compiles down to native C++ output making hardware calls and unlike Unity, does NOT rely on a virtual machine.
There's a few things here and there, not sure if there's an actual list. If you target flash, obviously you have all flash functionality available, but certain things (such as super-advanced international text field support) still need to be added on various targets. HTML5 is a brand new target so that's the least mature, whereas mobile and desktop targets have really good coverage. A "list of gaps we need to fill" would definitely a good feature to add to the OpenFL site, though.
OpenFL supports HTML5:
http://www.openfl.org/blog/201...
So any improvements to HTML5 will also benefit OpenFL.
What OpenFL solves is the issue of "shit, my platform holder's investors got bored and yanked the rug out from under me, time to build my workflow back together from scratch!"
By using Haxe, I can preserve my codebase and pivot to whatever the hot next technology is without having to bet on any one platform. I see that as a feature, not a bug.
Correct. I'm not an expert on the Haxe compiler, but I'm pretty sure it also has the ability (via hxlibc or hxcpp libraries) to directly compile Haxe to native binaries, skipping the intermediate C++ source step, but it can also create those too.
Okay, so that's a semantic difference then. If by "native" you mean "original source code written in the original language" than by that definition it's not native. I'm trying to clarify that it's not using a virtual machine, or relying on a plugin, whatever you want to call that.
It does not execute arbitrary C++ code on your machine. Did you even read the article? It's a lifeboat for flash developers to make, say, desktop games.
IT IS NOT A NEW VERSION OF THE FLASH PLUGIN.
It seems a lot of people either didn't RTFA or are basically misunderstanding what OpenFL is.
OpenFL is NOT an open source version of the flash Flash Plugin, like Gnash.
OpenFL is a code library written in Haxe.
You use OpenFL, and then you can output a truly native (C++) app, but can still use the flash API. It doesn't embed the flash player, or Adobe AIR, or anything like that, in your generated C++ app. You can use this to create truly native apps for mac/windows/linux/mobile, etc. Very recently they've added the ability to output to HTML5:
http://www.openfl.org/blog/201...
So you can take your old flash code, port it to Haxe, and then have a 100% Javascript based HTML5 game. And you can take that same Haxe code and make a native C++ app with it. And so on.
Hope this helps demystify things.
Slashdot Mirror
Send me an email at leveluplabs at gmail dot com !
Yeah, that's fair. I'd update the summary if I knew how; I thought that was implied as the last mile of any console solution is bound by proprietary terms, but in retrospect I see how it's confusing.
That's actually a concern of ours and we've designed the architecture around it to leave as much code as possible open source. To be clear we are NOT creating a new, non-open-source fork. We're using the existing public stack of OpenFL and Lime you can find today. However, as you can read in the article, we're building console-specific "batteries" that slot into the very last mile of the console stack as a separable library that can be safely distributed under the terms of console NDA's, without putting any burden on the existing public codebase.
Yes, it does use a garbage collector.
For the record, Haxe was created 10 years ago, before Typescript and transpiling was cool.
What you're basically asking for is the underlying Lime layer which is a part of this solution. The "OpenFL" part -- the Flash API implementation, is a convenience layer that would, yes, make it possible to port flash games to consoles, but the underlying Lime layer is pretty close to the metal and does as little as possible while unifying things like asset management and providing direct access to a consistent rendering API.
This compiles down to native C++ output making hardware calls and unlike Unity, does NOT rely on a virtual machine.
Why are they suggesting skipping straight to this hot mess instead of using a simple and well tested algorithm?
Nor sure I understand? The article explicitly argues for using this simple and well tested algorithm.
FlashDevelop is the most popular IDE for Haxe development, it does not "exclusively target flash/AIR."
Actually, several of the developers are major contributors to open source projects: Here's open-source libraries that are DIRECTLY the result of Defender's Quest development:
http://github.com/HaxeFlixel/f...
http://github.com/HaxeFlixel/f...
http://github.com/larsiusprime...
And here's my open-source report card:
http://osrc.dfm.io/larsiusprim... Nicolas Canasse, developer of Evoland, *created* the Haxe programming language. It's totally open source. Here's his open-source report card:
http://osrc.dfm.io/ncannasse Here's Sean Hogan (Anodyne/Even The Ocean)'s contributions:
http://osrc.dfm.io/seanhogan That's just off the top of my head.
There's a few things here and there, not sure if there's an actual list. If you target flash, obviously you have all flash functionality available, but certain things (such as super-advanced international text field support) still need to be added on various targets. HTML5 is a brand new target so that's the least mature, whereas mobile and desktop targets have really good coverage. A "list of gaps we need to fill" would definitely a good feature to add to the OpenFL site, though.
It already does! You can make native-binary mobile apps for ios and android using OpenFL, RIGHT NOW.
OpenFL supports HTML5: http://www.openfl.org/blog/201... So any improvements to HTML5 will also benefit OpenFL. What OpenFL solves is the issue of "shit, my platform holder's investors got bored and yanked the rug out from under me, time to build my workflow back together from scratch!" By using Haxe, I can preserve my codebase and pivot to whatever the hot next technology is without having to bet on any one platform. I see that as a feature, not a bug.
OpenFL already runs on tons of mobile devices, natively. Clearly, you did not read the article.
Again, you clearly did not read the article. For people who hate the Flash API, there is lime: https://github.com/openfl/lime
Sure, send me an email: http://www.leveluplabs.com/?pa... And let me know what you're dealing with. Chances are it's a haxelibs issue.
You clearly did not read the article.
Correct. I'm not an expert on the Haxe compiler, but I'm pretty sure it also has the ability (via hxlibc or hxcpp libraries) to directly compile Haxe to native binaries, skipping the intermediate C++ source step, but it can also create those too.
Okay, so that's a semantic difference then. If by "native" you mean "original source code written in the original language" than by that definition it's not native. I'm trying to clarify that it's not using a virtual machine, or relying on a plugin, whatever you want to call that.
It does not execute arbitrary C++ code on your machine. Did you even read the article? It's a lifeboat for flash developers to make, say, desktop games. IT IS NOT A NEW VERSION OF THE FLASH PLUGIN.
It seems a lot of people either didn't RTFA or are basically misunderstanding what OpenFL is. OpenFL is NOT an open source version of the flash Flash Plugin, like Gnash. OpenFL is a code library written in Haxe. You use OpenFL, and then you can output a truly native (C++) app, but can still use the flash API. It doesn't embed the flash player, or Adobe AIR, or anything like that, in your generated C++ app. You can use this to create truly native apps for mac/windows/linux/mobile, etc. Very recently they've added the ability to output to HTML5: http://www.openfl.org/blog/201... So you can take your old flash code, port it to Haxe, and then have a 100% Javascript based HTML5 game. And you can take that same Haxe code and make a native C++ app with it. And so on. Hope this helps demystify things.
Maybe because all the code is open source and you can inspect it yourself? http://www.github.com/openfl
OpenFL supports HTML5: http://www.openfl.org/blog/201...
You missed the part where OpenFL compiles to C++.