Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    DiscordBridge
    @DiscordBridge
    <thomasuster> And just make them non configurable
    <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>
    https://cdn.discordapp.com/attachments/162656395110514688/598449933561102360/unknown.png
    DiscordBridge
    @DiscordBridge
    <Beeblerox> I believe that it's hardcoded in TextField
    <Beeblerox> https://github.com/haxenme/nme/blob/master/project/src/common/TextField.cpp#L1882
    DiscordBridge
    @DiscordBridge
    <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?
    <IanHarrigan> heres nme:
    <IanHarrigan>
    https://cdn.discordapp.com/attachments/162656395110514688/598469459581337612/unknown.png
    <IanHarrigan> and heres openfl:
    <IanHarrigan>
    https://cdn.discordapp.com/attachments/162656395110514688/598469502795251712/unknown.png
    <IanHarrigan> apart from just being all round sharper the caret in nme is the right size also (pet peave in openfl)...
    DiscordBridge
    @DiscordBridge
    <Beeblerox> Hello! I have a question about deobfuscation of crash logs on Android target in NME
    <Beeblerox> i've used old OpenFL legacy and do it with ndk-stack which comes with Android NDK^
    <Beeblerox> like this
    <Beeblerox> ndk-stack.exe -sym "path-to-so-files" -dump "path-to-crash-log-file"
    <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
    DiscordBridge
    @DiscordBridge
    <Beeblerox> i have found this issue haxenme/nme#592
    <Beeblerox> so it seems that the only solution is to send stacktrace over http request?
    DiscordBridge
    @DiscordBridge
    <thomasuster> @Beeblerox Hey there, would you file an issue with reproduction steps, NME version, and ndk version?
    DiscordBridge
    @DiscordBridge
    <Beeblerox> will do today
    DiscordBridge
    @DiscordBridge
    <Beeblerox> Here it is: haxenme/nme#630