Is the SDL backend of app.h in working state?

[cblc]

In the docs of app.h you can read "even though only windows is supported right now", but however, the source code seems to have a SDL platform backend. I'm wondering if that backend can be used (in which case all the platforms supported by SDL would work), or if it's still WIP or with some features not working.

Also, I see that you put a set of OpenGL functions pointers inside a struct, which is something I like to do (because I wish to write apps which can be setup to either use the host GPU OpenGL implementation, or alternatively a software implementation based in Mesa through osmesa -even switching between both implementations at runtime would be possible, provided that the app sets all the OpenGL state during each redraw). Just for not reinventing the wheel, have you done something like this in any of your apps/demos?

Well, if I use app.h, I believe I'll need to customize it because my apps need to access OpenGL, and I think that you are hiding OpenGL from the client apps, so I'd add an API call that behaves as a redraw callback or something like that (as well as an API call for switching between the host GPU and the osmesa implementations).

[cblc]

Ah, another thing: If I decide to use it, I'd probably also add support for Mac Trackpad multitouch events in the SDL backend (not the low-level finger by finger, but high-level ones such as pinch-zoom, rotating, and panning, which are supported in recent SDL2 versions). If you are interested in getting that support, just tell me and I can do a PR with only those changes (I didn't code it yet, but it would be one of the first things I'd do if I decide to use app.h).

[mattiasgustavsson]

Yeah, the docs are lagging a bit, sorry about that. The SDL for app.h should be working fine as far as I know, but I am not using it much myself, being mostly a windows guy. But I have tried it on both mac and linux, and I know there are those who use it on those platforms, and I have not heard about anything being broken. There is also a web assembly backend for running app.h in a browser, and that one I do use regularly, and that definitely works.

I have not done anything like the switch GL/Mesa you describe, I just put the GL functions in a struct because on Windows I want to dynamically load and bind them, rather than linking a lib, but at the same time I don't want to use the global gl names in case some other part of the program wants to use gl by linking a lib.

app.h actually supports you doing custom opengl rendering. You would then use app.h as normal, and at startup, it will create a window and a gl context. When calling app_present, you can pass NULL as the first parameter, and then it will bypass the internal rendering of a provided backbuffer, and instead do just a swap buffers call. An example of this can be seen in my crtview program, where it is using crtemu lib to do the actual opengl rendering, and calling app_present with a NULL pointer to present to screen https://github.com/mattiasgustavsson/crtview/blob/6e8cb5c1d124e8f18046bf9966bc20109a71df4f/source/main.c#L248-L256
(it allows the user to cycle between 3 different mode, two of them using opengl themselves, and the last using app_present with an actual pointer to use the internal app.h gl rendering).

A more comprehensive example is my I ♡ Music program https://github.com/mattiasgustavsson/i-love-music where all the rendering of text and images is done with direct opengl calls, and app_present is used only to swap buffers.

I think for things like mac trackpad support, I don't want to bring too many things like that into app.h, as I want to try and keep it lean(-ish) if I can. Instead, I want to add for SDL something similar to the user_wndproc thing I have on windows, where users of app.h can hook intro raw windows events and do whatever they want. I was planning on adding something like that for SDL and WASM backends as well, but have not got around to it yet. But that's how I generally want to handle things that I consider outside of the core app.h functionality. For example, I use user_wndproc in I ♡ Music to handle windows systray events for the application.

Hope this cleared things up, feel free to ask more questions or ask for clarifications if necessary :)

[cblc]

Thank you very much for your detailed reply! I think then that I'll study app.h in more detail and, if appropriate, I'll customize it to my needs. Not sure if I'll do the customization by modifying the code or by including from another file that adds more features (which would seem to be preferred for easier updating to new versions), but we'll see.

I've also spent some time deciding about GUIs, and after a lot of comparisons, and because I don't feel like having now the time for writing mine, I think I'll pick Nuklear... not perfect because in each row of widgets it has automatic vertical sizing of the row, but not automatic horizontal sizing, but I couldn't find anything better unless I pick a C++ one such as ImGui, or NanoGUI, or even AntTweakBar. I think I have seen almost every C snippet of simple GUIs in GitHub, and Nuklear seems my best choice unless I implement mine.

Well, I'm closing the thread, and if I have more questions, I'll tell you.

Kind regards, and thanks a lot!!