Fantastic. It’s my understanding that SDL is responsible for why we can connect generic controllers to Linux without having to download specific drivers.
In my experience… not really. I would say SDL makes the task of writing controller support code within your own applications easier and higher-level, but in reality it still has not much to do with “drivers” (I assume you mean kernel modules), which the kernel and OS stack already provide multiple unified interfaces for with things like jsdev/evdev/udev/hidapi, regardless of how you access those subsystems (via SDL or otherwise).
Kind of. It’s the Linux kernel that manages all of the controller drivers and makes them available to userspace, mostly via the evdev interface. SDL is a library for managing graphics, sounds and events in a generic way on multiple platforms and devices. It’s overwhelmingly the most common library used for Linux games - Steam used it for all of their Linux-native ports of Source engine games, for instance. But it also presents all gamepad events in a consistent way regardless of their “true source”, so generic devices tend to work with every game.
SDL3 mostly clears out all the clutter from the previous versions of SDL. It’s a mature library and gamedev has come a long way in that time. Getting rid of all the weird stuff that the API accumulated makes it easier to use and maintain. Plus there were things like managing audio generally, and pen-and-touch gestures mobile phones and tablets, that were quite the head-scratchers before. That’s all a bit easier now.
SDL is kind of the equivalent to DirectX. It provides a standard interface for multimedia applications regardless of underlying mechanisms. Except the 3D acceleration part I think which is handled by OpenGL / Vulkan.
SDL3 has a new “GPU” API, which is some kind abstraction over Vulkan/DirectX12/Metal. I imagine it hides a bunch of boilerplate as well. With this, I think, one could do a 3D render engine without having to directly use the Vulkan API (or OpenGL, …). However, the shaders need to be in whatever format the backend expects it seems.
Fantastic. It’s my understanding that SDL is responsible for why we can connect generic controllers to Linux without having to download specific drivers.
In my experience… not really. I would say SDL makes the task of writing controller support code within your own applications easier and higher-level, but in reality it still has not much to do with “drivers” (I assume you mean kernel modules), which the kernel and OS stack already provide multiple unified interfaces for with things like jsdev/evdev/udev/hidapi, regardless of how you access those subsystems (via SDL or otherwise).
Kind of. It’s the Linux kernel that manages all of the controller drivers and makes them available to userspace, mostly via the evdev interface. SDL is a library for managing graphics, sounds and events in a generic way on multiple platforms and devices. It’s overwhelmingly the most common library used for Linux games - Steam used it for all of their Linux-native ports of Source engine games, for instance. But it also presents all gamepad events in a consistent way regardless of their “true source”, so generic devices tend to work with every game.
SDL3 mostly clears out all the clutter from the previous versions of SDL. It’s a mature library and gamedev has come a long way in that time. Getting rid of all the weird stuff that the API accumulated makes it easier to use and maintain. Plus there were things like managing audio generally, and pen-and-touch gestures mobile phones and tablets, that were quite the head-scratchers before. That’s all a bit easier now.
SDL is kind of the equivalent to DirectX. It provides a standard interface for multimedia applications regardless of underlying mechanisms. Except the 3D acceleration part I think which is handled by OpenGL / Vulkan.
SDL3 has a new “GPU” API, which is some kind abstraction over Vulkan/DirectX12/Metal. I imagine it hides a bunch of boilerplate as well. With this, I think, one could do a 3D render engine without having to directly use the Vulkan API (or OpenGL, …). However, the shaders need to be in whatever format the backend expects it seems.
Ah cool, that’s interesting.