sokol-zig
ffmpeg
sokol-zig | ffmpeg | |
---|---|---|
9 | 4 | |
279 | 120 | |
- | - | |
9.0 | 9.9 | |
11 days ago | 20 days ago | |
C | C | |
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sokol-zig
-
Zig cookbook: collection of simple Zig programs that demonstrate good practices
Zig currently doesn't allow chained designators and also doesn't allow to partially initialize arrays and fill up the rest of the array with default values.
E.g. the closest Zig equivalent to this C99 code:
https://github.com/floooh/sokol-samples/blob/b3bc55c4411fa03...
...is this:
https://github.com/floooh/sokol-zig/blob/a4b3c287fadd153a504...
...note how part of the initialization had to be moved out into "code".
There's a ticket about this here, but it's currently not high-priority:
https://github.com/ziglang/zig/issues/6068
-
Nim v2.0 Released
I maintain auto-generated bindings for my C libraries for Zig and Nim (and Odin and Rust - although the Rust bindings definitely need some love to make them a lot more idiomatic).
I think looking at the examples (which is essentially the same code in different languages) gives you a high level idea, but they only scratch the surface when it comes to language features (things like the Zig code not using comptime features):
Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples
Nim: https://github.com/floooh/sokol-nim/tree/master/examples
Odin: https://github.com/floooh/sokol-odin/tree/main/examples
Rust: https://github.com/floooh/sokol-rust/tree/main/examples
-
Zig Build System
IMHO you really need a programming language to describe a build, even when the result looks very declarative.
E.g. not sure how Meson handles this, but when I have a project with dozens of similar build targets and platform specific compile options, I really want to do the build description in a loop instead of a data tree.
(for example: https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029b...)
- Zig and WASM
-
Mach v0.1 - cross-platform Zig graphics in ~60 seconds
Is this project comparable to the zig sokol project?https://github.com/floooh/sokol-zig
-
How does zig magically cross compile without target shared libraries
I was rather amazed that I could cross-compile the zig-sokol examples https://github.com/floooh/sokol-zig for a Windows target on a Linux host (WSL Ubuntu). I simply set -target x86_64-windows and copied the executable into Windows and got a nice spinning cube displayed.
-
Mach Engine: The Future of Graphics (With Zig)
(disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers:
https://github.com/floooh/sokol-zig
This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline).
Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the WASM demos: https://floooh.github.io/sokol-html5/)
-
Making Win32 APIs More Accessible to More Languages
I'm tackling this issue from two sides:
(1) Change the C-API to make it more "binding-generator-friendly", for instance by adding a range/slice-struct to th C-API which bundles a pointer and associated size, or specially named typedefs that only exist to give the binding generator hints for special case handling.
(2) Make the bindings-generator configurable on a per-language and per-API basis, this can be as simple as a map which overrides type- and function-names, or injects manually written code into the generated bindings.
The goal is to make the generated bindings more idiomatic to the target language.
This mostly works if you have control over the underlying C-API of course, e.g. the language bindings are created by the original C-library project, not as an external project to convert a fixed C-API.
I wrote a blog post about this whole topic:
https://floooh.github.io/2020/08/23/sokol-bindgen.html
...and here's an example of one such semi-auto-generated Zig bindings, note the two "injected" helper functions at the top:
https://github.com/floooh/sokol-zig/tree/master/src/sokol
...for instance note the "injected" helper functions here:
https://github.com/floooh/sokol-zig/blob/1c93f60ad178869b84d...
-
Game Development
As you can see from the comments there are lots of options. Sokol is another one https://github.com/floooh/sokol-zig
ffmpeg
-
Odin Programming Language
And furthermore, C and C++ code can participate in the Zig package ecosystem. For example, here is ffmpeg packaged for consumption by a Zig project:
https://github.com/andrewrk/ffmpeg
Why not use a system package? Well, because the user's system might not have such a package. They might be on Windows, for example. Or their package might be out of date. [Or the system might have chosen sides in a nasty fork war](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html).
So, while system packages are nice for end users, they might not always satisfy the needs of upstream application developers.
-
Extend a C/C++ Project with Zig (2021)
It's a bit more nuanced than that, as detailed by AndyKelley (andrewrk@) on github[1].
As I understand it, C/C++ interop and support in the build system is not going away; instead it might be accomplished via a separately maintained clang package. (Aside: for an example of this kind of thing can work, see ffmpeg[2] converted to use the Zig build system which pulls in nasm[3] as a Zig package; presumably the clang solution would be a bit more integrated than that, but it serves to show that it can be done).
Zig will still support compilation using LLVM, but instead of directly linking to LLVM and using LLVM's IRBuilder API, it will directly output LLVM bitcode instead[4]. The build system will then handle linking this into an executable.
The idea seems to be to reduce dependencies of the main executable, while keeping the build system flexible enough that it does not impact existing use cases.
I'm not affiliated with the Zig project in anyway, so my understanding of this may be off. I'd recommend reading the GH issues and comments I've linked below to get a better idea of it.
[1]: https://github.com/ziglang/zig/issues/16270#issuecomment-161...
[2]: https://github.com/andrewrk/ffmpeg
[3]: https://github.com/andrewrk/nasm
[4]: https://github.com/ziglang/zig/issues/13265
-
WebRTC support being added to FFmpeg
I am not entirely sure with were you are going with this comment but FYI here is an ffmpeg fork with the build system replaced with a "build.zig" file and the Zig build environment: https://github.com/andrewrk/ffmpeg
-
Zig Build System
If you want to see a fun example of this build system in action, have a look at my ffmpeg fork which has the build system ported to zig build:
https://github.com/andrewrk/ffmpeg
Particularly interesting is the use of nasm as a package dependency, which is executed to compile many assembly files into object files, then linked into the ffmpeg static library.
I'm using this package in a work-in-progress reboot of Groove Basin (a music player server) in Zig:
https://github.com/andrewrk/groovebasin/tree/zig-pkg
Point being that if you want to collaborate on the music player project, you don't need to screw around with a million system dependencies, it's just `zig build` and you're off to the races - no matter whether you are using Windows, macOS, or Linux.
The zig build system is under heavy construction during this release cycle of Zig. I recommend to check it out at the end of May when Zig 0.11.0 is released, and a few more issues will be smoothed over. Of course, if you want to get your hands dirty and help work on a bleeding-edge build system & package manager, come on over and give master branch a try.
What are some alternatives?
zig-bgfx-sdl2 - Minimal zig project to get bgfx running with sdl2
raylib-zig - Manually tweaked, auto-generated raylib bindings for zig. https://github.com/raysan5/raylib
bigger - bigg (bgfx + imgui + glfw + glm) + utils
str0m - A synchronous sans I/O WebRTC implementation in Rust.
sokol-samples - Sample code for https://github.com/floooh/sokol
go2rtc - Ultimate camera streaming application with support RTSP, RTMP, HTTP-FLV, WebRTC, MSE, HLS, MP4, MJPEG, HomeKit, FFmpeg, etc.
go - The Go programming language
broadcast-box - A broadcast, in a box.
JNA - Java Native Access
webrtc-echoes - Simple useful interoperability tests for WebRTC libraries. If you are a WebRTC library developer we'd love to include you!
liwords - A site that allows people to play a crossword board game against each other
ffmpeg-webrtc - Support WebRTC(WHIP) for FFmpeg.