Erratic casting in `Rl.Image` variable declaration

[zikaora]

Haxe Code:

class Main {
    static function main() {
        var logo:Rl.Image = Rl.loadImage("Assets/logo.png")
        Rl.imageFormat(logo, Rl.PixelFormat.UNCOMPRESSED_R8G8B8A8);
        Rl.initWindow(800, 450, "Spatial");
        Rl.setWindowIcon(logo);
        ...

C++ Output:

    void Main_obj::main(){
                    HX_STACKFRAME(&_hx_pos_e47a9afac0942eb9_4_main)
    HXLINE(   5)        const char* this1 = HX_("assets/logo.png",72,b4,d1,0d).utf8_str();
    HXDLIN(   5)        cpp::Struct< Image > logo = LoadImage(this1);
    HXLINE(   6)        ImageFormat(&(logo),PIXELFORMAT_UNCOMPRESSED_R8G8B8A8);
    HXLINE(   7)        const char* this2 = HX_("Spatial",a4,f0,48,6a).utf8_str();
    HXDLIN(   7)        InitWindow(800,450,this2);
    HXLINE(   8)        SetWindowIcon(logo);

Build Output;

Error: Main.cpp
./src/Main.cpp(34): error C2664: 'void ImageFormat(Image *,int)': cannot convert argument 1 from 'cpp::Struct<Image,cpp::DefaultStructHandler> *' to 'Image *'
./src/Main.cpp(34): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
C:/Users/ACER/Code/Haxe/lib/raylib-hx/source/lib/src/raylib.h(1231): note: see declaration of 'ImageFormat'

[foreignsasquatch]

try the latest commit please say if this persists

[zikaora]

sorry for the delay, the issue still persists unfortunately :(

[foreignsasquatch]

will look into it more then

[zikaora]

I've been able to get around this by using RlImage directly

/** Image, pixel data stored in CPU memory (Ram) **/
typedef Image = cpp.Struct<RlImage>;

https://github.com/foreignsasquatch/raylib-hx/blob/main/source/Rl.cpp.hx#L249

Is there a reason why we're using the cpp.Struct<> cast here? perhaps i'm missing something @foreignsasquatch

[foreignsasquatch]

Im using cpp.Struct so it doesnt create a dynamic array when creating for example Array

[foreignsasquatch]

I think this can be closed? because this is very use case specific

[zikaora]

I'd argue that it's a pretty common use case. Plus it practically renders all Rl.Image objects incompatible with any of raylib's image functions. But as I have no solutions in mind, I guess closing is fine

[foreignsasquatch]

will fix again