Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Info] Sokol luajit direct use version #1127

Open
dlannan opened this issue Oct 16, 2024 · 2 comments
Open

[Info] Sokol luajit direct use version #1127

dlannan opened this issue Oct 16, 2024 · 2 comments

Comments

@dlannan
Copy link

dlannan commented Oct 16, 2024

Last weekend I put together a luajit sokol that uses ffi and linked sokol dll's
Currently only tested on Win. But should work on MacOS and Linux (will check this weekend).
This is just an issue if people are interested.

https://github.com/dlannan/sokol-luajit

Want to thank @floooh for making Sokol. Its been a very interesting framework to use and quite a bit more powerful than I expected :)
The fork for luajit is slightly tampered with, but I hope to get the luajit header generation working nicely and some auto patching as well - cimgui being a bit of a pain with luajit (not being really C).

Again thanks for Sokol, I also hope to contrib if possible as I progress with this.

@floooh
Copy link
Owner

floooh commented Oct 16, 2024

Woah, very cool!

Are you planning to integrate this with the automatic binding generation scripts in the sokol repo (https://github.com/floooh/sokol/tree/master/bindgen) - this would automatically update the files here (https://github.com/dlannan/sokol-luajit/tree/main/ffi/sokol) and push to sokol-luajit whenever the sokol headers change.

...then a separate CI job in the sokol-luajit repo could rebuild and commit the precompiled DLLs (although that might grow the repository pretty quickly... the other bindings don't have binaries committed but instead helper scripts to build the them... a build.zig could be the least painful option for that...)

The only thing that would need to be updated manually is then probably fixing the examples from time to time in case of breaking changes.

Also the shader compiler integration is impressive :D Would it make sense to add an official Lua code generator to sokol-shdc? I'm very surprised how little code this is:

https://github.com/dlannan/sokol-luajit/blob/10c6ecb417448d3abf2a564b25e875d969a0013c/tools/shc_compile.lua#L44-L126

...significantly less than a sokol-shdc code generator...

Btw... bug (the win32 path)?

https://github.com/dlannan/sokol-luajit/blob/10c6ecb417448d3abf2a564b25e875d969a0013c/tools/shc_compile.lua#L39

Can Lua detect x86 vs ARM Macs? In that case you could add both the x86 and ARM macOS exes.

Anyway, great stuff! :)

Cheers :)

@dlannan
Copy link
Author

dlannan commented Oct 16, 2024

Hi, thanks, and really you did all the hard work :) (Im just leeching :) ).

I looked at trying to setup some binding, but there are some complilcations I want to figure out first before going that route - ie, what does each target need - currently android and wasm are not happy for various reasons. Wasm is complicated because building luajit using something like emscriptem wont work because of its dynasm system - it might be possible to make a luajit dynasm wasm target, which would be awesome, but theres a couple of other ways around I wanna try first.
The android problem is issues with shared libs, so Im looking at a more integrated approach - luajit + sokol + some libs to provide a 'good enough' runtime, but that needs investigation too.

So yes. Will get to generation one day.. but as you prob know.. sw dev goes slow at the best of times :)

I dunno how stable/friendly the shader compiler is. Its rudimentary ( I really want runtime adjustable data sets, and shaders are one of those). I'll spend more time on it, since Im looking at making a Defold shader import to be included in it (probably as a param setting), because I have a tun of Defold shaders I'd like to try out :)

The pathing. yes... this is just wonderous. And I will definitely be making an agnostic path manager (have built a few before for lua) which will make paths across systems a little more consistent. This is kinda tricky to get right though, so once I have that in a better state can be a bit more confident in its use.

Yes lua can detect diff platforms. However, this is only with luajits ffii module. You can use the properties ffi.os and ffi.arch. Extremely useful for handling the platform issues. But should go in a single lua defines or something to handle it more appropriately.

Thanks again, really enjoying playing around with sokol. Hooked it up to luasocket and copas and made a little http server running in the sokol game loop. Really nice api you built so I greatly appreciate what you (and Im sure others) have done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants