https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • f
    I'm making assumptions here, but if it's not Kha or OpenFL, doesn't seem to happen with vanilla hxcpp, but does happen for both of us with HaxeUI... begs the questions how on earth this relates to UI!
  • b
    Yep. I tried wrapping a map and having .keys() return my own Iterator with some better typing. But that just reduces the crash frequency a bit and doesn't actually change the fact that map.keys() is a Iterator (in my StringMap case), and so still just a typedef dynamic.
  • f
    > reduces the crash frequency ooof. Mine either crashes at launch or doesn't crash. I'm guessing you can't reproduce it just vanilla haxe?
  • b
    My project is currently to involved to pull Haxeui out and check. So I can't say Haxeui is necessarily involved. But when Haxeui shows up in the crash call stack, it's when it's looping through EventMap. Which, well, uses map.
  • f
    Mmh :/ Tricky
  • b
    Ian found that, in my case, changing the hxcpp optims or removing them makes a big difference. Crashes Way less often, but way slower without optims. So the hunt for a fix goes on. Was hoping your case may provide clues.
  • f
    :/ I'll let you know if I discover anything!
  • b
    You should try adding -D HXCPP_GC_DYNAMIC_SIZE That might help in your case.
  • f
    Thanks, I'll give it a shot. Get this for an update, right: When I render my 250,000 sprites with Kha with a grid scale of 1, it crashes, when I render them with a grid scale of 2, it doesn't crash. I've tested a number of times, it's not just random. Go figure!
  • b
    Wow... that makes negative sense.
  • f
    It's crazy
  • b
    In fairness to the parts of my stack, Haxeui included, my issue is quite unique to our complicated setup. My project is compiled to a static lib, is dll wrapped, and, well, it's complicated. We stop and start lime update, so gc has a lot of room to go nuts. If I compile to just an exe, there aren't any crashes.
  • f
    Sounds like hell to debug :/ Fair enough though, I similarly doubt that Haxe UI is involved in my issue any more than the thing that calls something that breaks it all
  • f
    Go figure though why a scale of .999 works, 1.001 works, but 1 doesn't 🤦‍♂️
  • b
    I would try to talk to Rob about it, sounds fun. 😄
  • f
    I was just about to make a Kha exclusive test case 😄 No doubt, this test case won't have the issue
  • b
    Yeah. And for me, maps in cpp Are kinda awful. However, crashing in map iterator is almost certainly a symptom of whatever the larger problem is. If maps were better and I wasn't crashing on them, I'd be that much closer to spotting the real issue. Map crashes are basically obscuring my view of the real issue.
  • f
    Not sure if this means anything (earlier it seemed like Math.floor was directly changing whether it crashed!) but moving my massive array to be a class var instead of a function variable has prevented (for now) it from crashing 🙂
  • b
    For gc reasons, that makes a lot of sense. So your array is Array?
  • f
    It's Array, where 
    Tile
    is a class that includes about 5 Floats
  • b
    Gotcha
  • b
    I similarly reduced my problem by using class vars for maps. It was Way worse before doing that. Unrelated but general rule of thumb for me on cpp (and any static target) is anything dynamic and anything like an anonymous function is the devil.
  • c
    Glad i saw this, may solve an issue i'm having.
  • f
    Cheers for that issue fix Ian, can't do any Haxe work tonight but I'll take a look as soon as possible 👍
  • b
    sweet, nice one
  • b
    going on a bug hunt 😉
  • b
    would like to get a v1.1 out to haxelib this weekend... lets see though, got a big list of stuff to get through for it
  • f
    Very nice 😄 Final exam for me is Tuesday, so just a couple of days before I can go 100% with this project. Keen to help improve Haxe UI Kha in any way I can too 😄
  • b
    perfect, sounds ace... 👍
  • c
    How does item renderer works btw?
1...295296297...1687Latest