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
(Sorry for my delay. I was making a Global Game Jam Location)
I don’t understand where do I put -verbose on flash develop. I can’t find the build settings. I searched about this before making the question but I was unable to find it.
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
Not always does this. Usually it works after trying a few times. It is not always on the same place. After that I did another build and it showed this when it crashed:
The bug seems to be fixed on the neko side and require a rebuild from source but personnally I havn’t had any luck on getting it to run but perhaps I didn’t rebuild Neko correctly.
msbuild neko_vc10.sln
msbuild libs/libs_vc10.sln
copy /y libs\include\gc\gc.dll bin
cd src
neko ../boot/nekoc tools/install.neko
neko tools/install -nolibs
cd ../bin
nekoc release.neko
neko release.n
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
Ok, using this example, it does seems to works, with the new build of neko this run as expected instead of having the “Uncaught exception - std@module_read” even without DCE or NO INLINE
class Main extends flash.display.Sprite {
public function new () {
super();
var tf = new flash.text.TextField();
tf.text = "Hi There";
addChild(tf);
var space = new nape.space.Space();
}
}
However using my game I still get the error and it’s not a huge game (simple pachinko physics game) the neko file is 1.2MB
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.
At least two options exist – we could use JavaScript, in the form of a node.js application (using the C++/SDL windowing) or node-webkit (using DOM windowing), and we could use Java (using our same C++/SDL windowing or another window library)
Either Java or JavaScript will compile fast like Neko, JavaScript even more so, and either could be good for both testing or cross-desktop builds (say, Mac builds from Windows)
Do you have any opinion on whether either of these choices would be suitable for you? Should we consider this, or stick with Neko?
Neko is also much slower than JavaScript or Java in raw number crunching, and is susceptible to unique quirks (like a default value of “null” for int/float values) which makes it less resilient when it is used as a quick testing target
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.
and it’s not a huge game (simple pachinko physics game) the neko file is 1.2MB