A .NET wrapper for https://github.com/floooh/sokol, primarily sokol_gfx; a simple and modern wrapper around GLES2/WebGL, GLES3/WebGL2, GL3.3, D3D11 and Metal.

Includes the C style API precisely as it is and a .NET style API for convenience.

To learn more about sokol and it's philosophy, see the A Tour of sokol_gfx.h blog post, written Andre Weissflog, the owner of sokol.

The P/Invoke bindings are a pure port of the C headers; they exactly match what is in C, and the naming conventions used in C are maintained.

The structs in C# are blittable, meaning they have the same memory layout as the C structs. This allows the structs to be passed by value (copy of data) or reference (akin to copy of pointer) from the managed world of .NET to the unmanaged world of C as is.

In .NET, the unsafe keyword will most often be necessary for using the C structs and calling the C functions. Also, for practicality, it's recommended to import the module with all the bindings, structs, and enums like so:

using static sokol_gfx;

To learn how to use the C API, check out the official C samples. You can also find the same examples that run in your browser. The comments in the sokol_gfx.h file are also a good reference.

The .NET style API is a modification of the C bindings (from the side of .NET) to be more idiomatic and overall easier to use. The unsafe keyword is not required.

The .NET API currently targets .NET Core 3.1 (LTS). Included with .NET Core is the System.Numerics namespace which Vector2, Vector3, Matrix4x4, are used. Span<T>, Memory<T>, and friends are also used which live in the System.Memory namespace that is also part of .NET Core. This results in code remaining small, highly performant, and easy to use without re-inventing the wheel. Using .NET Core also allows for easy support for desktop platforms and soon mobile, browser, and console platforms. More about platforms in the next section.

All the types are .NET value types. This is to get as close as possible to zero allocations on the managed heap during the long running state of the application's loop. This is often desirable in games and other demanding, high performance, applications.

To learn how to use the .NET API, check out the samples, which are in sync with the official C samples.

The following is a table of the same .NET API samples ordered by their complexity.

Name	Description	GIF/Screenshot
Clear	Clears the frame buffer with a specific color.
Triangle	Draw a triangle in clip space using a vertex buffer and a index buffer.
Quad	Draw a quad in clip space using a vertex buffer and a index buffer.
BufferOffsets	Draw a triangle and a quad in clip space using the same vertex buffer and and index buffer.
Cube	Draw a cube using a vertex buffer, a index buffer, and a Model, View, Projection matrix (MVP).
NonInterleaved	Draw a cube using a vertex buffer with non-interleaved vertices, a index buffer, and a Model, View, Projection matrix (MVP).
TexCube	Draw a textured cube using a vertex buffer, a index buffer, and a Model, View, Projection matrix (MVP).
Offscreen	Draw a non-textured cube off screen to a render target and use the result as as the texture when drawing a cube to the framebuffer.
Instancing	Draw multiple particles using one immutable vertex, one immutable index buffer, and one vertex buffer with streamed instance data.
MultipleRenderTargets	Draw a cube to multiple render targets and then blend the results.
ArrayTexture	Draw a cube with multiple 2D textures using one continous block of texture data (texture array).
DynamicTexture	Draw a cube with streamed 2D texture data. The data is updated to with the rules of Conway's Game of Life.

Since sokol_gfx is a C library technically any platform is possible. However, currently only desktop platforms (Windows, macOS, and Linux) are supported with Sokol.NET by using .NET Core 3.1. In November 2020, Sokol.NET will move to .NET 5 and support mobile (iOS, Android), browser (WebAssembly), consoles (Nintendo Switch, Xbox One, PlayStation 4), and micro-consoles (tvOS). See .NET 5 annoucement as the next .NET Core that will unify desktop, mobile, browser, consoles, and other platforms.

sokol_gfx converges old and modern graphics APIs to one simple and easy to use API. To learn more about the convergence of modern 3D graphics APIs (such as Metal, DirectX11/12, and WebGPU) and how they compare to legacy APIs (such as OpenGL), see A Comparison of Modern Graphics APIs blog written by Alain Galvan, a graphics software engineer.

The following is a table of platforms that are known to work and their supported graphics API backends with sokol_gfx in C.

• ⭕ means the graphics API is supported on the platform but not by sokol_gfx.
• 🚧 means the graphics API will be supported by sokol_gfx but is currently under construction (from sokol side).
• ❗ means the graphics API is deprecated on that platform but can still work with sokol_gfx. OpenGL is deprecated for macOS. It is recommended to only use Metal for macOS if hardware supports it. All Apple platforms support Metal.
• ❓ means the graphics API is unofficially supported. Vulkan has limited support on macOS and iOS. Vulkan is not yet supported on tvOS.

To get the NuGet packages, add the following feed: https://www.myget.org/F/lithiumtoast/api/v3/index.json

Sokol.NET uses calendar versioning and semantic versioning where appropriate. For example, the version scheme used for native shared libraries such as sokol_gfx is YYYY.MM.DD and the version scheme for Sokol.NET is MAJOR.MINOR.PATCH-TAG.

Sokol.NET uses GitVersion to determine the exact semantic version for each build in Continuous Integration (CI) and Continuous Deployment (CD).

How GitVersion is configured for Sokol.NET, the version is automatically bumped by +0.0.1 after each pull-request. Also, tags are considered releases; when a new tag is created, the version is automatically bumped to the specified version on the tag.

For a complete list of the release versions, see the tags on this repository.

Sokol.NET is licensed under the MIT License - see the LICENSE file for details.

Do you want to contribute? Awesome! To get started please read the CONTRIBUTING file for details on our code of conduct, the process for creating issues, and submitting pull requests.

For information about the authors, contributors, and maintainers, see the MAINTAINERS file.