Its not free of bugs, but its a starting point. Pull requests are welcome.
Also all the sdl-c library functions are stripped in favor of the c.libc package
7 Likes
I tried to build the main.odin file but there were some issues.
There is no check for loading a lib file when OS is Windows so I had to add that in (I created the lib from the dll using ālibā in dev cmd prompt, maybe I screwed something up).
In the main file, CreateGPUDevice requires GPUShaderFormat as an argument which is only present as an u32 when it should be a bit_set. I added those in and then it did build but running it didnāt open a window so I donāt think itās working, Iāll have to investigate further.
The enum fields have redundant names like PropertyType.PROPERTY_TYPE_INVALID instead of PropertyType.INVALID. I get itās probably to be consistent with the original api but vendor:sdl2 doesnāt do this. Would it maybe be a good idea to keep it consistent with that instead?
Btw, why arenāt you using c types like c.uint instead of u32? I realize those are just aliases but it should be easier to avoid bugs with them. Is it to avoid importing a package?
Anyway, Iām not saying you need to fix these things. Maybe Iāll make a PR once I get all the issues sorted out, but that might take a while. I want to take my time and make sure that itās mostly functional. Thanks for doing the bulk of the work by the way, it really helps!
You are absolutely correct. I can make the bindings in odin-style like the sdl2 package. I should and I would. Help is appriciated.
And also as I use linux, Ive just made the linux port. Other platform support has to be added.
1 Like
For SDL3, weāll support official bindings when it is officially released, which I believe is January 15.
Since it is not officially released yet, just āABI stableā, I will not post the bindings yet.
15 Likes
Nice! Iāll still try to get it work on my end just as a learning experience, but Iām glad it will be officially supported.
1 Like