I’ve been trying to bring Haxe & OpenFL to GCW-Zero by a long time. I am already able to run native code on the device through hxcpp. The real problem is OpenFL, as I don’t have any idea what I should do next: lime, lime-next, lime-tools, nme, aether? Each time I take a look the things looks different.
So, what are the OpenFL dependencies right now?
For additional information, GCW-Zero runs a mips based linux OS and now has SDL2 & OpenAL support.
Thanks.
You got hxcpp on it, that was the first step,
it has sdl2 & openal support that’s awesome and it’ll fit perfectly in the codebase since it uses them for all native target including (work in progress) mobile.
nme is separate from lime/openfl now, so unless you want nme support there too you don’t have to worry about it.
lime-tools/aether, the tooling part is now in the lime project repository, you’ll have to do a little work on this to, at the very least, add the target. https://github.com/openfl/lime/tree/master/lime/tools
How do you currently build a haxe project for the gcw-zero?
Does-it have an emulator or some way to push code on it? If so then it would have to be added to the tools too.
So now what you need is for lime to run on it,
a quick reminder of lime vs lime next, long story short next is the, well, next version of lime,
most likely where you want to go, it’ll make your porting way easier.
You’ll need the lime ndll built for the gcw-zero architecture, since you have hxcpp support it shouldn’t be too hard.
It’s done by the tool so probably somewhere around here https://github.com/openfl/lime/blob/master/tools/CommandLineTools.hx#L128
Then you can test it with one of lime’s template lime create
I skipped a lot of step but hopefully it’ll help you get started.
I didn’t mention openfl I know, it’s full haxe and run entirely on lime, so once you have lime working openfl should follow really quickly.
Cool project, and good luck!
Hello ibilon, thank you very much for the great and fast reply 
Knowing where to start will help a lot, I was completely lost.
Thanks again!
You’ll also want to decide whether you want to add support into the Lime 1 “legacy” path, or the newer Lime 2 path.
In the Lime “legacy” path, you’ll find the files under “lime/legacy/project”, which is a bit more complicated, but this has it’s roots in the NME project.
In the newer Lime 2 path, the native backend is under “lime/project”, and might be easier to start with. I usually start there, then backport if it’s something important.
Being Linux-based, is this something that could use a Linux platform target, or how many things are distinct over a regular binary for Linux?
I think I’ll take the easy way for now, using the newest lime version.
The major differences over a regular Linux version are the low screen resolution (320x240), the absence of keyboard & mouse, and the lack of OpenGL (only supports OpenGL ES). So it’s like a mix of linux & mobile
Thanks!
All right guys, I’ve added GCW-Zero Platform on lime. You can see my diffs here.
I’m testing the Hello World example, I was able to build it using the command “haxelib run lime build gcw0” whithout errors.
Running HelloWorld on my device I got the following error: “Error : Null Function Pointer”.
Any tips on how I can debug the application?
Thanks!
EDIT: Probably because lime.ndll is missing, my bad 
Is it working? 
I still need to build lime.ndll, editing Build.xml now
BTW, I’ve had a hard time determining whether “zero”, “gcw-zero”, “gcw0” or just “gcw” is most appropriate for the target. If they come out with a new device, I wonder if they will keep the “zero” or if it will have a new name, and whether it will be backwards compatible
There also there’s the possibility of “linux -gcw0”, similar to the older “linux -rpi”, not sure
Me too, in some ports I define GCW_ZERO, GCW-ZERO or GCW0… I vaguely remember someone mentioning that the next device would be GCW-ONE, but I’m not sure.
Yeah, maybe. The only big difference here is that it’s not a desktop type linux 
I’m having some trouble to build lime.ndll. Editing project/Build.xml I’ve noted that all dependent libraries (sdl, png, openal, etc) are under the ‘lib’ dir is that right?
Is there a way I can use my own precompiled libraries from my toolchain? SDL, for example, is not officially supported and I don’t own the code adapted by GCW-Zero team, I only have access to the compiled library.
Everything is statically linked and built together, we use a standard SDL2 build, but if this does not include support for the platform, then there’s two options. One would be to modify our SDL2 copy in order to include the optimizations needed. Another would be to have another reference, similar to how we have “openal” and “openal-android”, though it’s nice to avoid this where we are able. I suppose that precompiled binaries would be an option, but this ends up being a headache when there’s a bug (how do I build that again?), there’s a new architecture, etc, but it might be a good way to start
Oh, glancing at http://www.gcw-zero.com/develop, it looks like it might include SDL2 in the toolchain? Perhaps there’s a way to simply use the SDL2 includes (but not the files) and then “-lSDL2” or something, this is how Emscripten ended up working, you should see some Emscripten specific conditionals in the Build.xml.
If you need to do an “and” in the if/unless of the XML, BTW, you can do so with a space, like if="hello world", and “or” is handled with ||, like unless="foo || bar"
Yes, SDL2 library is distributed precompiled in the toolchain with its respective headers. The same version is also included in the firmware as a shared object, so every updated device has SDL2 available.
I’ll try that “emscripten approach” tomorrow. Thanks again, Joshua.
Finally lime.ndll was built, but still no luck here, I’m getting “Illegal instruction” now. I am probably doing something wrong, here are my changes. I saw some GPH defs in the code, is it fully supported?
Which project are you testing? I would recommend Lime’s “HelloWorld” sample as the first step, and see if you can get that to run
Yes, I’m using lime’s HelloWorld sample
How can I force the screen size to 320x240?
For now, I’d just set <window width="320" height="240" /> for now, in the project. You might also need to add messages to try and see if it gets past the Haxe boot into the ApplicationMain, and if there, if it gets into the constructor of your class, and so on, to make sure it isn’t tripping up over Haxe standard library stuff, like tracing