Do you get any other output? You could add -verbose To FlashDevelop’s build settings, and then see when this occurs, it is probably in the build tool somewhere, I always test from the command prompt so maybe there’s something different that’s tripping up on one step
If nowhere else, you could even do it in the target drop down, which is editable, change “windows” to “windows -verbose”, and the drop-down will remember both options, so you can switch between them. Otherwise, somewhere in the project options I think there’s a place for additional build arguments
copy /y libs\include\gc\gc.dll bin
neko ../boot/nekoc tools/install.neko
neko tools/install -nolibs
Run it inside the Visual Studio Command Prompt. You should get a .zip in the bin folder. Makes sure you have 7za in your PATH as well as SP1 update of Visual Studio I think.
Evrything seems to go well except I always get a “Uncaught exception - load.c(237) : Failed to load library : std.ndll” when trying to compile/run a neko OpenFL game… So I must be missing a step somewhere.
Ok turns out you need to update the DLL inside the template folder (or bin/), still that now gives me this error
Called from zpp_nape/callbacks/CbType.hx line 348
Called from nape/callbacks/CbType.hx line 179
Called from nape/callbacks/CbType.hx line 198
Called from zpp_nape/callbacks/CbType.hx line 174
Called from zpp_nape/callbacks/CbType.hx line 353
Called from zpp_nape/ID.hx line 186
Uncaught exception - Invalid operation (+)
I think that it is a problem with the resulting size of the Neko binary. If I remember properly, Nape uses a LOT of inlining, which performs well in Flash, but not perform as well elsewhere. If it is the binary size, then debug vs. release, or which project uses Nape, could trigger the threshold it crosses. It might be interesting to try --no-inline to see if it makes a difference
I’ve been thinking for a while about a Neko replacement. I’d be open to your ideas on this subject.
I enjoy Neko for three potential reasons:
Consistent platform tools (the “openfl” or “lime” command)
A fast desktop testing target
The (unutilized) ability to do cross-desktop compiles
I think Neko is more than sufficient for #1, but I’ve been questioning #2 and have never gotten #3 out of it.
One option would be to work with Neko more directly, to contribute to the project and help make it more suitable as both #2 and #3, potentially. Another is to use a different runtime for this.
Do you have any opinion on whether either of these choices would be suitable for you? Should we consider this, or stick with Neko?
Is there a code size limit for Neko? I’ve had a project get to the point where it won’t run under Neko any more, and the only thing I can think is that it crossed some size threshold.
I always liked using Neko to iterate quickly, until I ran into that problem, and until I found the null default value making a difference to my tests.
If there is an option to use something that compiles quickly and allows for reliable application testing, I’m sure that many people would find it useful. If you can continue to support Neko at the same time, that’s great.