Slashdot Mirror
Open Source Haxe/OpenFL Platform Will Support Home Game Consoles
lars_doucet writes: At last week's World Wide Haxe conference, a coalition of game developers announced that the open source platform Haxe/OpenFL is coming soon to home game consoles. The first three games that will ship using the technology are Yummy Circus, Defender's Quest (HD edition), and the award-winning Papers, Please.
Haxe is a programming language that compiles to other programming languages (everything from C++ to Javascript to Python), has been around for about 10 years and is quite powerful. OpenFL is a hardware-accelerated cross-platform reimplementation of the Flash API, built on top of Haxe (but does not have the Flash player's performance and security limitations and has nothing to do with Adobe), and is built on a low-level cross-platform layer called Lime, which can be used separately for those who have no need for a Flash-like API. This could eventually lead to console compatibility for engines that are built on top of Haxe/OpenFL, such as Away3D, Stencyl, HaxeFlixel, and HaxePunk.
Six console targets are planned: Wii U, PS4, Xbox One, PS Vita, 3DS, and PS3; footage of demos running on the Wii U was presented at the talk and are included in the linked article.
Six console targets are planned: Wii U, PS4, Xbox One, PS Vita, 3DS, and PS3; footage of demos running on the Wii U was presented at the talk and are included in the linked article.
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.
I've been looking through the Haxe documentation, but I can't see how it does memory management. Does anyone know? Is it garbage collected?
"First they came for the slanderers and i said nothing."
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.
And you are charging for the console batteries, and they are not open source. The summary makes it sound like everything is open source and free, but the console stuff is not. I'm not being judgmental here: I understand why that stuff can't be free and open, but the summary is somewhat misleading.
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.