Add support for SOKOL_NOAPI backend

[castano]

I often want to use sokol_app on Vulkan applications. Vulkan support has been requested in the past: #535, but it does not appear that this will be offered in the near future.

However, it's fairly easy to use Sokol for the window creation and event handling functionality and keep all the Vulkan-specific code in the application code. In my initial implementation I was simply providing a VkInstance in the app description and sokol_app's only responsability was to create a VkSurface. I think that was unnecessarily complicated and caused problems with the shutdown order. The surface needs to be destroyed before the instance, but after the swapchain, so it's not possible to rely on the cleanup callback to destroy all the vulkan resources at once. Instead it was much more simple to move all the responsibilities to the app and make the sokol_app code API agnostic.

So far it does not seem to be necessary to add additional callbacks. In my applications API initialization is done on init, shutdown on cleanup, and resizing of the swapchain in response to the SAPP_EVENTTYPE_RESIZED event.

This certainly needs more testing and validated on other platforms, but I'm putting it out as a draft PR in order to gather feedback.

I think one could also use this feature with other APIs such as OpenGL, Metal and D3D11, in order to gain more control over some aspects of the swapchain without having to modify sokol_app's internals. For example, supporting custom formats or controlling the presentation mode

Note, I added the const void* sapp_android_get_native_window(void) API in order to obtain a pointer to the ANativeWindow, which is necessary in order to create a Vulkan surface. I also moved the EGL attributes out of the _sapp_android_t struct and used the _sapp_egl_t struct instead. This is what's causing most of the changes in this PR.

[floooh]

Apologies for not responding yet. I'll try to catch up with PRs over the next couple of weeks.

[pplux]

Hi! I was going to suggest also a "NOAPI" approach, in my case to manually handle webgpu on native (linux, mac, windows). It will be very useful, and practical to only use sokol_app for the window creation, events, etc... but manually let the user handle the graphical context.

I would like to do this also on linux and mac, but for now I will only test on mac, will you be open @floooh to this?

@castano I can help with mac, and maybe linux later.

[floooh]

Yeah I'm definitely in favour of the idea to have a NOAPI mode for sokol_app.h, at least if we can find a solution that doesn't require too big changes to the platform-specific backend code (e.g. ideal would be wrapping the code that sets up the 3D device/context and swapchain inside an if, but I don't know if that idea is too naive).

[pplux]

At least, speaking for webgpu, existing init and cleanup methods are more than enough to get it working with no issues. It will be useful to have a post-window closed cleanup too, but I can manage to work around it by using the NOENTRY approach and controlling exactly when sokol ends. With a extra post-cleanup callback I wouldn't need it at all, but it is fine.

[pplux]

I built a minimal native wgpu app with sokol, using @castano NOAPI define here:

https://github.com/pplux/minimal-wgpu-native

It was needed on Windows, otherwise it will crash at destruction when the GL context is destroyed (after wgpu overrides it).

On Mac, the Metal backend seems to work fine out of the box.

[dortamiguel]

I also have a vulkan application and I will like to use sokol only to handle the window and the events. Is it hard to implement a custom vulkan context that creates the surface? I'm not sure where to start to make something like that

[pplux]

Hi @floooh, is it anything we could do to help with the NOAPI approach? I'm still thinking this is a veeery nice feature for sokol_app for others to build on different render backends (like wgpu in my case). Can we help in any way?

[floooh]

@pplux I think a series of smaller PRs which only touch one backend platform at a time is the most realistic option. Preferably with code blocks inside #ifdef SOKOL_NOAPI moved into a function.

[pplux]

OK! I'll try to rework the NOAPI platform by platform 👍