https://linen.dev logo
Powered by
# haxe-ui
  • b
    i was using flixels mouse coords, which are calc'd based on camera zoom
  • b
    which makes sense
  • b
    so now i just use the openfl events mouse x/y
  • b
    Oh
  • b
    it does mean that if you have your ui in a zoomed camera the coords will be wrong again
  • b
    I'm wondering if that generalizes
  • b
    yeah, i defo think there is a better way to do it, but for 99% of cases a 1x zoomed ui is going to be the norm
  • b
    but yeah, that was the fix
  • b
    itd be better ofc if, eventually, the mouse system is totally camera aware, but at the moment, honestly, i think this is just fine
  • b
    So flixel does iterate each camera to see if the mouse is overlapping
  • b
    the "problem" is there is no "is mouse over" for a FlxSprite, right?
  • b
    In flixel or the backend?
  • b
    There's a mouse over event in flixel
  • b
    But I don't see one in the backend
  • b
    is there a mouse over in flixel? For a sprite group?
  • b
    even for a sprite might work
  • b
    Ok I see what you're doing
  • b
    There is no flash mouseover in flixel since everything is pixels within a big bitmap
  • b
    yeah, thats what i thought
  • b
    There is flixel's own mouseover
  • b
    But it's janky and I basically rewrote the input manager to make it less janky
  • b
    But still janky
  • b
    its just a big bitmap with "stuff" in it
  • b
    at least thats how i saw / understood it
  • b
    Basically
  • b
    i mean, even groups in flixel are just that, groups... no hierarchy
  • b
    so i think it all makes sense, but certainly good to get another (far more experienced) pair of eyes on it
  • b
    It doesn't generalize, but it does work for most cases like you said
  • b
    its kinda more similar to the kha backend now
  • b
    yeah, ideally it'll in the future it will be camera aware, but honestly, apart from looking for ways to break it, i cant really think why you would have a zoomed ui in a camera
1...397398399...1687Latest