Add a sokol-gfx backend

[SasLuca]

We should consider moving the renderer to something like sokol_gfx or sokol_gl in order to provide graphics backends for Metal and DirectX.

Particularly, providing a Metal backend is important because OpenGL is deprecated on iOS and MacOS.

This would be a big change however and add an extra dependency.

[SasLuca]

We might be adding a Vulkan backend instead which means that we won't need to use sokol_gfx. Vulkan can also be made to run on iOS and MacOS (https://moltengl.com/moltenvk/). Nintendo Switch also supports Vulkan and PS5 and the new Xbox might support Vulkan. So hopefully with a Vulkan renderer, we will soon have renderer to rule them all.

[hbiblia]

Segun escuche ahora Vulkan cuando esta en IOS y MacOS utiliza Metal

[truedat101]

@SasLuca do you mind answering a question about the path you were on here? I see you have a branch called "better-org".

Do you mind laying out the roadmap you had in mind? (No commitment of course as I know you are on to other stuff). But I would like to understand the laundry list of what is left on "better-org" to finish. My objective is to get metal backend going, and alternatively maybe a vulkan backend, but metal is the priority. Based on the 0.9x branch work, this is somewhat difficult as a path because the glad / GL is prominent in the API and there isn't a clear way to port without a redo of the design.

But looking at the better-org, you've altered the design for the backends I think was to make this transition easier to support ports: rayfork/sources/gfx I still think the metal backend (I guess via sokal-gfx) is a better approach for mac/ios/vision os , simply because the general feedback from the VK approach on mac is that performance is superior direct to metal, and the transition from GL to Metal is a closer reach.

Anyway, any blueprints you can share on the approach you were on, I am interested in working through this. One thing I've noticed is some of the libraries in third party need a refresh given the age, and I will work through that. Since I am on Mac, I am finding issues that will need to get resolved. I will go back through on Linux after this.

[SasLuca]

Hi @truedat101, thanks for your interest in the library. In the past I kinda gave up on it because I was too busy at work and also I was lacking a bit in vision for which direction to take this project in. Also the lack of time didn't allow me to research the most important bits related to it, such as graphics.

If you are interested in contributing I am a bit more free now and could get involved again, but I would need to make some decision related to the extent and purpose of the library. If you are interested in discussing on another channel about this you can also reach me on Discord where I am @bananyadev.

The laundry list on "better-org" is that I had an idea of separating some more general utility aspects of the library from the game aspects (for example I was writing a C string api that I think could be useful to people outside of game dev and a dynamic array api) and just generally reorganizing the project. Also audio was a feature I didn't get to fully port from raylib.

[truedat101]

Hi @SasLuca thanks for the reply. As mentioned on another thread, I kicked the tire a bit on raylib for some non-game dev related projects, and was quickly impressed, and disappointed too that it wasn't ever going to get onto ios platforms. I bounced to raymob (a similar sort of fork that is android focused and pretty good, patched a few things there on my own fork that I needed to work). I stumbled onto rayfork, as I need or would like something similar on ios/vision os. Most of my experience in graphics / vr / audio has been in porting and release engineering. I will follow up on discord to further discuss.

[truedat101]

BTW just sent a friend request on discord : truedataio

I couldn't figure out how to get onto a private #rayfork group on the raylib discord.

[truedat101]

Any thoughts on audio?

Looking through sokol api header for audio:

    Link with the following libraries:

    - on macOS: AudioToolbox
    - on iOS: AudioToolbox, AVFoundation
    - on Linux: asound
    - on Android: link with OpenSLES or aaudio
    - on Windows with MSVC or Clang toolchain: no action needed, libs are defined in-source via pragma-comment-lib
    - on Windows with MINGW/MSYS2 gcc: compile with '-mwin32' and link with -lole32

Is it a lighter lift to link with a single library that ports well across : lin win mac ios?

Candidates might be:

• portaudio
• https://www.attr-x.net/yse/ ... I'd never heard of this but it looks interesting
• https://github.com/LabSound/LabSound
• http://libsound.io/

I haven't deep dove on the implications of what raylib needs. basic one shot/looping/mixing?

[truedat101]

Perhaps the above should be moved into an issue tracking audio support? Sorry, I forgot this thread is gfx.

[SasLuca]

For audio in C the best library nowadays is https://miniaud.io/ which wraps the native audio apis on multiple platforms including iOS. Raylib also uses this.

[truedat101]

Ok, nice, I tried out miniaudio on a local mac test. Seems nice. I will try it on ios/visionos. Would you use the raylib flavor of miniaudio?

[SasLuca]

Yeah I am thinking of just copying the raylib miniaudio wrapper but adding allocator awareness like.

I also recently got more free at work so I am looking forward to work more on rayfork this month.