Implementing custom hardware cursors in SAL took less than a lazy Sunday, whereas getting the scaling and positioning right for multi-monitor support took me several weeks. It is not always the flashiest feature that eats up the most development time.
SAL offers the function salChangeWindowMonitor(), which not only allows moving the SAL window to another monitor but also maximizing it or even setting it to Windowed Fullscreen on the target monitor.
This feature proved extremely painful to implement, and it took far too long to get it right.
Short answer: It bothers me, that's why. Having said that, the real benefit of SAL's design is a clean separation between OS scaffolding and user code. OS events never stall the render loop, so the freezes that single-threaded apps are susceptible to (not only when resizing but also for example during device hot-plug, high message frequency due to precision input devices, and so on) are simply gone.
Showing of SAL (Simple Abstraction Layer), a GLFW-like library I'm working on. The idea is to offer only the features that are needed for game development while at the same time removing annoyances such as freezing or stuttering of the scene when resizing the window.
Edit: I realize the attribution is hard to see in the video. The shader is by Otavio Good. Check out his work at https://t.co/mtBkdwpyuG
Zig is a beautiful language. I hope one day there will be Zig bindings for SAL.
I admit I'm a bit worried about porting SAL to macOS. On Windows, I basically reversed the traditional setup and have the main thread as the render thread and a dedicated worker thread as the window thread with the message pump, which is harder, if not impossible, on macOS.
@JohnShaffstall Certainly, I expect to have version 0.1 ready to put on GitHub soon. Having said that, SAL will always just have a subset of SDL3 and GLFW features. I'm really hell-bent on keeping the Simple Abstraction Layer, you know, simple.
The first feature that comes to mind is multi-window support. All a game typically needs is a container to put the framebuffer in. Next would be the somewhat more obscure window properties such as passthrough and transparency.
Of course all this is debatable. My philosophy is: Design the framework to be extensible, but don't write all the extensions you can possibly think of upfront.
When working with the basic building blocks of a game engine, the lack of text rendering out of the box in OpenGL is painful. Check out https://t.co/pZ1YlQ22Cz for an easy drop-in to get some simple text rendering done.