Or, just put me on a space craft, and then make the earth travel at relativistic speeds, so that time for everyone goes slower than for me, and thus I'd be able to finish the C binding generator tommorow (at least from everyone else's point of view).

... so, its certainly doable... but really not for the feint hearted i dont think. ( @User / @User )

*fainthearted I think

there really is quite alot of moving parts... its not impossible, but defo a maintenance burden

haha, yeah, i meant "faint of heart"

feigning a heart is defo NOT what i meant 😄

so, Zeta, id be interested in some initial feedback on this, its just a test, but generating this might be a decent idea - but before i think about that, just wondered if you could cast your eyes over this PoC and see if anything jumps out as "crazy"

For

Color

I'd do

@:struct @:structInit class

which let you do

c
HL_PRIM void HL_NAME(hl_raylib_clear_background)(Color* color) {
    ClearBackground(*c);
}

oh yeah? Thats nice

@:struct

gets rid of the extra

hl_type*

field on hashlink classes. Now, one thing I just remembered: I think

@:struct

will only work on latest hashlink from git, and not with 1.11.

hmmm, right... so is this way "ok" until that becomes more mainstream?

You could also do a normal class and

c
typedef struct {
  hl_type *;
  Color c;
 } hl_color;

HL_PRIM void HL_NAME(hl_raylib_clear_background)(hl_color* color) {
    ClearBackground(color.c);
}

I'm not really a fan of typedefs because they're a bit slow.

right, interesting, but i would assume that would be faster than a bunch of

hl_dyn_geti(color, hl_hash_utf8("r"), &hlt_i32);

type things?

Classes will definitely be faster than typedefs.

oh yeah? So the way im doing it currently would be faster than a typedef?

Not sure I understand. The way you're doing it currently is using a typedef...

oh yeah, haha... sorry... thought it was a class

i guess a typedef just turns in a map of some kind?

On the haxe side you can also do this:

hx
@:hlNative("raylib","raylib_")
class RayLibHL {
    public static var RAYWHITE:Color = {r: 245, g: 245, b: 245, a: 255};
    public static var GRAY:Color = {r: 130, g: 130, b: 130, a: 130};
    
    public static function initWindow(width:Int, height:Int, title:String) {}
    public static function windowShouldClose():Bool {
        return false;
    }
    
    public static function closeWindow() {}
    public static function beginDrawing() {}
    public static function endDrawing() {}
    public static function clearBackground(color:Color) {}
    public static function measureText(text:String, fontSize:Int):Int {
        return 0;
    }
    public static function drawText(text:String, posX:Int, posY:Int, fontSize:Int, color:Color) {}
}

the haxe compiler wll automatically convert

initWindow

to

@:hlNative("raylib", "raylib_init_window")

OK, thats good to know too... i had some issues with the names initially and just went with "what worked" in the end

ah, heres a q i meant to ask... how does HL reslove hdlls? I mean, at the moment as part of the build im copying the hdll to the bin folder, but obviously that doesnt make sense for a haxelib

also, what about pointers? Like

void*

, or

void**

The compiler will auto-magically do

camelCase

=>

snake_case

when you have`@:hlNative` on the class. As for hdll resolution, that's just `dlopen`/whatever windows does, so however the OS resolves dynamic libraries.

Depends on what the

void*

represents. random user data =>

vdynamic*

=>

Dynamic

A blob of data =>

vbyte*

=>

hl.Bytes

For

void**

,

hl.Ref<Whatever>

.

ok, i guess i meant

void**

really... normal pointers are probably easy enough

so

hl.Ref<vdynamic*>

is valid? (i havent tried at all yet)

hl.Ref<Dynamic>

. On the C side that would be

vdynamic **

.

ah, doh, yeah... sorry, mixing it up again...

so with your hl kinc stuff... where do you put the hdll? Do you have some method to put it next to the .hl?