ah cool

so i do not think it would be causing the issue

indeed

does it work for other targets?

yes

i normally test on cpp and occasionally html5

including hxcpp ?

OK sweeet

could be a discrepancy between hashlink and hxcpp bindings

hashlink have its own bindings here:

(somewhere up there is same bindings for older or newer prime way of cpp-bindings [or neko;])

So if you change something there to test out, you need e.g. a

lime rebuild hl

has the cpp function binding

I was wrong, looking at the wrong function lol

ok - I was about to ask

this is how it _diffs_:

haxe
@:cffi private static function lime_image_data_util_copy_pixels(image:Dynamic, sourceImage:Dynamic, sourceRect:Dynamic, destPoint:Dynamic, alphaImage:Dynamic, alphaPoint:Dynamic, mergeAlpha:Bool):Void;
// hashlink:
@:hlNative("lime", "hl_image_data_util_copy_pixels") private static function lime_image_data_util_copy_pixels(image:Image, sourceImage:Image, sourceRect:Rectangle, destPoint:Vector2, alphaImage:Image, alphaPoint:Vector2, mergeAlpha:Bool):Void {}

yeah so hashlink does it's fun little wrapping thing for all the types

where hxcpp uses Dynamic

sooo one of the hashlink wrappers could be error ing

yep (hashlink did it better strictly ;:)

I'm learning a lot from lime hashlink bindings

the last few days trying to eat that soup with a fork

still barely know what I'm looking at but it's starting to stick

OK I think I've found the cause of the bug

if I force it to call the function here, then it does not crash

ah, then it is if

alphaImage

is not null AND

alphaPoint

vector2 is null ?

(definitively if one of them is not NULL 😂)

yeah the weird thing is...

cpp
if (!alphaImage) {
  ImageDataUtil::CopyPixels (image, sourceImage, sourceRect, destPoint, NULL, NULL, mergeAlpha);
}

this is correct, because alphaImage is NULL

so it should work