https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • h
    Gotcha . . . well it did look nice haha. I guess I'll revert for now
  • b
    so, in a perfect world, how would you foresee that working in haxeui? What would 
    new HaxeUISubImage(khaTexture, frameX, frameY, frameW, frameH)
    be returning?
  • b
    oh, sorry, misread, its not a function its a class
  • h
    Right. If it isn't clear it would just keep texture and subimage information. It's probably not completely necessary, as you could just include the single images needed for HaxeUI outside of the atlas, but I was just seeing if this is reasonable or even existed.
  • b
    i guess something could be added to the ImageDisplayImpl.hx in haxeui-kha - but im not sure what that would look like
  • b
    then you could go: 
    myHaxeUIImage.getImageDisplay().drawSubImage(...)
    (drawSubImage being a new function in haxeui-kha)
  • b
    alternatively this could be a nice place to test out the extensible image loaders (described in the 1.6 notes), but i still dont know what it would actually look code wise under the hood... can you give me a (preferably working) example of your tilemap thing (without haxeui), the thing im "stuck" on is that under the hood, ImageDisplayImpl uses a kha.Image as buffer
  • b
    actually, alright, i think i get it now, so if ImageDisplayImpl held info about the tilemap, and the cords, then this would also have to change to then draw that sub image: https://github.com/haxeui/haxeui-kha/blob/master/haxe/ui/backend/ComponentImpl.hx#L311-L317
  • h
    Right something like 
    DrawImage(this, x, y, w, h)
    right?
  • b
    or drawsubimage, or whatever... the thing i wasnt understanding is, i was thinking it will still use the _buffer under the hood, but ofc, thats the whole point, you dont want that, so it will be another "type" of image really
  • h
    I'm not sure how the buffer you're talking about works. I think you'd still supply the buffer but additional information on where on the buffer you'd draw in. But I don't know haxeuis internals enough to know if that's right
  • b
    well, the _buffer is a kha.Image that gets loaded from assets and gets blitted as part of the renderTo
  • b
    and i think you want to side step that altogether, i mean, i could reuse the _buffer variable, buts its now a ref to some "global" kha.Image, not one that is created by haxeui
  • b
    do you have a tilemap to play with?
  • h
    Yes I'll send you one
  • h
    If you are considering adding this in - may I suggest adding support for supplying scale information? IE: you supply the resource with the subimage information and scaling information? Or do you think HaxeUI will work on the scale part of things?
  • b
    yeah, im going to have a play, and yeah, i was defo going to add support for drawScaledSubImage
  • g
    any idea on how i can keep these false errors from showing up? everything compiles but theyre kind of annoying(haxeui-openfl)

    https://cdn.discordapp.com/attachments/565569107701923852/1100196877443539104/image.png▾

  • g
    everything is up to date
  • e
    they arent false in the context of the completion server
  • g
    well then how can i make the completion server recognize haxeui?
  • e
    make sure that haxeui is actually included in the hxml that it uses
  • e
    since its openfl, the hxml is created from the project.xml
  • g
    well the xml has haxeui added
  • e
    have you restarted vscode since adding it?
  • g
    Copy code
    xml
    <haxelib name="haxeui-core" />
    <haxelib name="haxeui-openfl" />
  • g
    yes
  • a
    did you recompile after adding them?
  • g
    it was the same thing yesterday, im just now coming back to it
  • g
    well ive ran 
    openfl test html5
    , does that build it beforehand?
1...164616471648...1687Latest