angle VS sokol-samples

It's using MoltenVK on Mac for Vulkan compatibility, and ANGLE for OpenGL compatibility on Windows and Linux. Makes you wonder what it's actually doing itself.

Can't they use https://github.com/google/angle?

BTW. For the last 15 years, all web browsers on Windows do WebGL on top of DirectX (using the Angle library https://github.com/google/angle).

You can still use OpenGL. Just not the vendor provided drivers. They are indeed horrible. There are libraries like:

* ANGLE ( https://github.com/google/angle ) - An OpenGL ES implementation with Direct3D 9, Direct3D 11, Desktop GL, GL ES, Vulkan and Metal backends. This is what we used to use for shipping our Qt 3D application, that used a bunch of OpenGL Shaders. We used to get bug reports about various shaders not working properly on various hardware. After switching to this, all those bug reports vanished.

* Zinc ( https://www.supergoodcode.com/do-not/ ) - A more recent, OpenGL implementation on top of Vulkan. I haven't used this one yet. But they are making a lot of progress and it is almost as performant as vendor provided OpenGL Drivers these days. So if I ever have to ship a desktop app, needing opengl, I'd strongly consider using this.

Another option if perf isn't a big concern is to try using Google's angle OpenGL ES 3.0 implementation, there's backends for it to be supported on Vulkan, Direct3D 11, and (work in progress) Metal. Disclosure, haven't tried it myself, just looking at their feature descriptions: https://github.com/google/angle

I don't believe Chrome uses OpenGL directly- any OpenGL usage it does have (e.g. for WebGL) is actually going through ANGLE which translates it all to D3D on Windows.

RTFM, have you read their instruction

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

This is a simple Pong-like I've written in Raylib compiled to WASM - https://wasm-stuff.netlify.app/pong

Source code is here: https://github.com/rrampage/skitter/tree/master/pong-raylib

It is fairly straightforward to get Raylib running in the browser. I used @flohofwoe's HTML shell file ( https://github.com/floooh/sokol-samples/blob/master/webpage/... ).

PS: also if shader functions could be directly defined "inline" in regular CPU code (and behind a special function pointer type), there would be no need for string literal shenanigans like this:

https://github.com/floooh/sokol-samples/blob/3f10c1a0620cec9...

(and shader compilation would happen during the regular build and would also generate regular compiler errors - with current toolchains that's only possible with a lot of build system magic)

I think something along those lines (rarely used...) was also given by the C++ Committee as justification why so much of the C99 designated init feature set was left out of C++20. But in reality, all C99 designated-init 'sub-features' complement each other nicely once you start using them. It's a great way for building 'data-driven' APIs.

For instance check out this call to create a 3D-API pipeline-state-object in C99:

https://github.com/floooh/sokol-samples/blob/ad9047e228a8441...

I'm using anonymous nested structs extensively for grouping struct items, but I consider the extra field name a feature, not something that should be hidden:

https://github.com/floooh/sokol-samples/blob/bfb30ea00b5948f...

(also note the 'inplace initialization' which follows the state struct definition using C99's designated initialization)

It's an STB-style single-file library, which means the implementation is in a separate ifdef-block from the interface declarations, this allows to compile the implemenentation in a separate source file (which can be a C file), and be used in different source files (which can be C++ files).

For example (using stb_image.h):

https://github.com/floooh/sokol-samples/blob/master/libs/stb...

C99 has made all that a lot easier, you can setup, initialize a struct and call the function taking a pointer to that struct all in one call:

https://github.com/floooh/sokol-samples/blob/89f5825ab5d3690...

The Win32 window system functions and D3D11 are actually very convenient to work with in C99, better than C++ actually.