yeah, at first i thought it was haxeui-flixel, but then i replaced the "crates" with a flxsritegroup with a single flxsprite in it, and it worked just the same (as in didnt work, or worked strange)

then i remove the flxspritegroup and used just a flxsprite and that was fine, then i changed (hacked) haxeui-flixel to use a base of Flxsprite (rather than a group) and that also worked "fine" then... in the sense it collided correctly

sure... just thought i would test it with something "flixely" and collision seemed like the best bet

but i guess there is something about flxspritegroup that is very different to flxsprite

or, more likely, something i wasnt doing - but the fact that without haxeui, and a flxspritegroup the demo didnt work as expected surprised me

If components are treated as flxsprites stored in an flxgroup, it should behave normally. Whether that's actually doable is beyond me.

That is, make haxeui components be flxsprites

Then group them together in a parent flxgroup

The biggest problem would be render but... flxsprite's dirty flag, plus adjusting its sprite/graphics, might work

The actual internals there are going to look a little strange.

(Also, I have no idea if that even works with HaxeUI's expected model, either.)

Components can have children though, so it makes sense for everything to be a group or sprite group

If it’s a group, the outcome will be super kha-ish, but that’s fine tbh, more lightweight than sprite group

also, keep in mind that my initial foray into the flixel collision demo didnt work with FlxSpriteGroup, but that doesnt mean it cant... its either a) a flixel bug b) a flixel design or c) something i did wrong... and i would be heavily leaning to "c"

That’s kinda what I’m expecting 😉

yup, me too 😃

If it does work, im gonna leave the structure alone for a bit before doing the FlxGroup kha style thing

I think there are other features to add over an internal structure thing

makes sense, i mean, the only issue i had with the group is it didnt work... ... but then... ... "c" 😃

i think set_x and set_y probably need to be override too... and there were some other "strangities" that i do think come from haxeui-flixel... but im sure you'll notice what i mean when you start playing with the collision sample

Oh wait

So you expect component.x to work the same as .left?

Cuz that for sure won’t work

I’m mid-travel so I haven’t checked the demo yet, but I’ll be home soon enough

well, again, my "expectation" is mainly just high level... in the sense that i would "expect" to be able to integrate haxeui into flixel, and in that respect flixel animates .x and .y

so in that collision demo, i would have expected that i could replace the "crates" with haxeui buttons (not hard - ignoring the FlxSpriteGroup thing) and then they collide, rotate and move... collide wasnt hard, move needed an override (which screwed up other things, but i think that could be fixed with a bit of maths in the override) and the rotate i think worked also

but yeah, im sure you'll see what i mean when you have a mess around... and you are no doubt in a better position to just be "yeah, well, x/y/z needs to happen in ComponentImpl"

Insofar as what Ian's describing, an FlxGroup of FlxSprites appears to achieve all the required checklist points. * It must have a drawing surface which it manages (FlxSprite manages that for individual components, and at a higher level FlxGroups manage that for their children) * It must have physics handled by the implementing system if any are present (physics apply to FlxSprites, and at a higher level physics interactions such as collision handling can be performed on FlxGroups) * locations should be co-integrated between HaxeUi and implementing backend (FlxSprites have an X/Y ; Groups are lacking parity here and would need additional work). It appears what is missing is an object which correctly composes itself of multiple FlxSprites in a way where it also, in turn, behaves exactly as an FlxSprite. This may explain why FlxSpriteGroup was chosen; it tries to do that (?) . A better alternative would be an implementation of a FlxGroup which contains the requisite behaviors, and specific implementations of specific entities may need to be reduced to single FlxSprites. (Should a button's text be a separate object from a button's background? Etc. kind of questions)

... Always a reminder that my experience is old, and I may be wrong on specific details.

Ian, a concrete checklist may make it simpler for implementers to see where the best place, architecturally, to slot it in may be, if you have one in mind.