<thomasuster> And I can add warnings in NME if you go below required min for the ABI.
<thomasuster> or error
<thomasuster> And have defaults be the ABI default.
DiscordBridge
@DiscordBridge
<codeservice> Agree, in most cases it can be 16/21 for best old devices support. Unless some one need different API or if we want support multiple NDKs for for exaple using API14 from older NDK and API21 from latest.
<codeservice> As more you think about it as more it gets tricky :) hard to say at what level of complexity we need this. Hard coded 16/21 work for me.
DiscordBridge
@DiscordBridge
<thomasuster> :thumbsup:
<thomasuster> I think we can actually just hard code to 16 right? Since there is no device that is <21 that is 64 bit.
<thomasuster> I could check that.
DiscordBridge
@DiscordBridge
<thomasuster>@codeservice Okay it should be good now. I also changed it so when you run "test" it only build the architecture for the device you have connected via adb. If you run haxelib run nme build android -gradle it will build all 4 apks.
<thomasuster> Added this after getting some feedback from @hughsando
DiscordBridge
@DiscordBridge
<codeservice> Looks good and minimize to level 16 reasonable. If someone need 14 he kand exclude NDK20 toolchain and use older version.
<thomasuster> Yep π
DiscordBridge
@DiscordBridge
<thomasuster> Yea itβs no longer a breaking change i think
<thomasuster> Unkess they didnβt set minsdk
DiscordBridge
@DiscordBridge
<codeservice> And now interesting question when we can see it all live. From what i understand hxcpp should go first. Hope soon π°
DiscordBridge
@DiscordBridge
<thomasuster>@codeservice π Yes, HXCPP first. Then NME. I just want to make sure Hugh is comfortable with the HXCPP diff before it lands.
DiscordBridge
@DiscordBridge
<codeservice> π no problem. More issues can be found when developers start using it.
DiscordBridge
@DiscordBridge
<IanHarrigan> anyone have any idea how nme decides what colour to use for text selection?
<IanHarrigan> for some strange reason, it always wants to select text as white
<IanHarrigan> nice one, thanks... in fact it seems that it was because the the size of the textfield (height) was smaller than the font... means it was drawing the chars as white but not the blue background of the selection
DiscordBridge
@DiscordBridge
<IanHarrigan> So text rendering in NME seems much much sharper then in openfl... what engine does it use? Howcome openfl does use the same / similar one?
<Beeblerox> and this prints me stack at the moment when app crashed
<Beeblerox> but for some reason i don't get the same result for NME builds of application
<Beeblerox> could you give me hints on how to do it?
<Beeblerox> (i've wasted couple of days trying to achieve something, but had no luck with it)
DiscordBridge
@DiscordBridge
<Beeblerox> it just look like i'm using stripped so-files, but i'm building app with -debug flag and they are much bigger than files built with -release flag
<Beeblerox> for my experiments i'm using modified bunnymark demo, but crashes when i tap on the screen (i've added two lines for it: var s:Sprite = null; var x = s.x; at stage_onMouseDown method)
DiscordBridge
@DiscordBridge
<Beeblerox> and btw i'm building my app with gradle
DiscordBridge
@DiscordBridge
<Beeblerox> i've tried arm64 build today and it seems a bit better, but the only thing i see is that build crashes on unhadled exception which was caused by some code in touch handler, but it don't provide me much details about the source of crash (like method and class names and line numbers of my faulty code)
DiscordBridge
@DiscordBridge
<Beeblerox> and on windows debug build i'm instantly get that error is in my Main file with the line numver
DiscordBridge
@DiscordBridge
<Beeblerox> plus i've also compiled my app with -DdebugSymbols flag (which tells not to strip debug info from build in openfl-legacy), but it seems like in NME it's not accounted
DiscordBridge
@DiscordBridge
<Beeblerox> i'm sorry not debugSumbols but HXCPP_DEBUG_LINK