I tried updating to OpenFL 6 before, but the game immediately crashed (on Windows 10). Windows says the program has stopped working. If I choose Debug, Visual Studio shows:
Now I traced it down to this line:
language = openfl.system.Capabilities.language;
If I remove it, the game works again (in Windows).
Anyway, I wanted to try to release an Android version with the builds that Vega suggested, however, it seems like the admob-openfl library is not compatible:
D:/haxetoolkit/haxe/lib/admob-openfl/0,0,3/com/pozirk/ads/Admob.hx:26: characters 7-23 : Type not found : openfl.utils.JNI
Thanks, I can compile admob-openfl now, so I tried the new version on Android and it crashed. After removing the same line (openfl.system.Capabilities.language) it worked on my phone, so it looks like the same thing as on Windows. However, on my Nexus 7 tablet it didn’t work (Unable to initialize the shader program), but I see that there is an active thread about that.
Anyway, I decided to publish this version to see if it fixes the crashes on Android 7, I guess I’ll know in a couple of days…
My system language is English (location is Netherlands though) and the versions are Openfl 6.5.0 and lime 5.8.2.
I wonder if we should use LOCALE_USER_DEFAULT instead of GetSystemDefaultUILanguage() and LOCALE_NAME_USER_DEFAULT for the second parameter… maybe it would work the same. Seems odd that we don’t use a pointer type for the third parameter, locale, it seems like it should be &locale instead?
However, this function might not be safe to use from a static variable. Do you try and access the language in a static initialization variable, or do you reference it later?
The following code works for me, here (both before and after the change, but now the language and region are returned instead of only language):
package;
import openfl.display.Sprite;
class Main extends Sprite {
public function new () {
super ();
trace (lime.system.Locale.systemLocale);
trace (lime.system.Locale.currentLocale);
trace (lime.system.Locale.systemLocale.language);
trace (lime.system.Locale.systemLocale.region);
trace (openfl.system.Capabilities.language);
}
}
Hmm, I still wonder if this is a problem of static initialization order. Would you mind trying a basic sample, similar to the code I was running, and see if that has a crash as well? If you updated your GIT version (and haven’t already), you may also need to try git submodule init && git submodule update && lime rebuild windows -clean from the LIme directory
Would it be too much trouble to do a little bit more debugging? I wish I could reproduce your crash, but I can’t so far, so a few more tests would really help to identify the cause of the crash
The @:isVar here seems questionable, you could try removing it. You could also put traces around this call, to see if this is where it crashes
I tried removing @:isVar, but then I get: This field cannot be accessed because it is not a real variable Add @:isVar here to enable it
But you are right about where it crashes. I traced it further into CFFI.hx and found that it crashes on the following line: result = __tryLoad ("./" + library, library, method, args);
It doesn’t get to the next trace.
Build succeeded
Done(0)
haxelib run lime run “project.xml” windows -debug
Running process: D:\HaxeToolkit\haxe\haxelib.exe run lime run “project.xml” windows -debug
Main.hx:14: hello
CFFI.hx:145: ./lime
Done(1)
EDIT: I also traced inside the __tryLoad function.
Strangely, it doesn’t seem to get past __loaderTrace ("Got result " + name); (traces after that don’t show up).
If I comment out that line it continues.
I finally got it to work by disabling the __loaderTrace function completely.
Main.hx:14: hello
Main.hx:16: en_GB
Main.hx:17: en_GB
Main.hx:18: en
Main.hx:19: GB
Main.hx:20: en
Looking at the __loaderTrace function, it seems that this line causes the problem:
var get_env = cpp.Lib.load ("std", "get_env", 1);
And “get_env” was also showing up when I first tried to debug in Visual Studio, see screenshot above. The call stack also shows tryLoad and loaderTrace.
