at time of writing, it can only init and terminate but it is very good at it.
i wrote it over the last few nights in my favorite lispy programming language: janet using spork/cjanet, the build process generates c bindings as instructed by the code i wrote using the DSL cjanet offers for writing bindings then these generated c files which also handle wraping and unwraping of values, are compiled against a static build of glfw3.
in case this compile works, the glfw3 api probably hasnt changed since last time this was touched (well, it is a work in progress but i could revisit this chost and add when i finished it) and you have a native module generated using janet code.
this is like finding out you dont have to get off your bicycle to get across the street but you can in fact pedal across like all the other traffic. the bicycle here is the programming language janet, as writing c code is, to me, tedious and error prone. so, being able to use a c-writting-DSL interspersed with janet code to generate bindings during runtime? absolutely doable. something is slower than expected and you want to try to push it into a cfunction? and then encapsulate it into a native module? for leisurely browsing your filesystem and perusing whatever functions are available? taking them for a spin actually? just a matter of whether you want that functionality or not i guess..
i had started handwriting the wgpu binding and got as far as having:
- init
- terminate
- create-window
- destroy-window
- wgpu-create-instance
- glfw-get-wgpu-surface
- request-adapter (for now, until i get to rework this part i was using the requestAdapter helper function from the tutorial and this is a wrapper, well just like all the others are also just wrappers xD)
so yeah.
i hope i can just include the requestAdapter function somehow for now, so i dont have to replicate all THAT in cjanet///
i am soooooooo looking forward to actually drawing something onto the screen again...
addit: can you tell im really tired?