I generally agree, as long as it concerns such thick abstraction layers as SDL which make it very hard to work around its shortcomings. That's why I mentioned GLFW which is a very thin layer - it only abstracts the window management but does it in a way that it's still possible to get around it.dpJudas wrote:Because I don't think interfacing X11 is particular tricky (done it before). The biggest catch are the window manager hints, which I admit is a PITA, but on the other hand once you've paid your taxes for Linux desktop WM hell, you no longer have to rely on distros updating SDL for Vulkan support, for example. Essentially the same reason I prefer my own solution on Windows and macOS - the cost of writing the platform binding is one-time early on, but the benefits of not having the abstraction lib between you and your platform is worth it in the long run.
I find it a bit puzzling that almost every other port out there settled on SDL and constantly has to deal with some problems by using such a Linux-centric library on Windows. SDL 1.x was particularly problematic if you just happen to use a non-standard keyboard layout. I have no idea what the SDL guys have been doing but they somehow managed to change the system setting in a way that it got Windows to activate its language changer in the status bar. Back in the early days when I was still working on a PrBoom derivate one of the first things I did was to get rid of SDL because it constantly stood in the way of doing things right.
Nice video. It sums up the problem I have with Linux mostly. One directly applies to GZDoom: On Windows and macOS it's a trivial matter to get a string, give it to the system along with a font and a size and retrieve a perfectly usable graphic for the text. On Linux - no such luck. The system has no facilities and with third party libraries we are again at the mercy of those users who are unwilling to install the needed libraries for whatever reason - be it that their distro of choice does not provide the needed version or they have some irrational antipathy towards one of the dependencies and what not. Fortunately I am not directly involved with this at work but my colleague who is responsible for our software's Linux deployments can tell endless stories about this stuff and how much wasted work it costs. In the end it's just cheaper to equip all working desktops with Windows and forget about this support nightmare.dpJudas wrote: Edit: Sorry for the harsh words, but I completely agree with Linus Torvalds when he commented on "Why Linux Failed On the Desktop".
It all depends. Yes, we have our own Windows backend, our own macOS backend and our own SDL backend.dpJudas wrote: I get why people feel you need an abstraction library just to target that platform, but I don't think that applies anywhere else. What got me commenting in the first place was Graf talking about using one of those abstraction libs for Windows. That I feel is a bad idea when there's already a perfectly working solution in place. I'm sure those are fine libs but I don't think any of them does it better than the direct GZDoom code built for Win32 today.
What if we needed an Android backend - or an iOS backend - or a backend for the next hot thing that comes along in 5 years.
While they 'work' they also cause work. Fortunately not much but it's there. So if there was a practical way to fold it all into one piece of code and offload the backend maintenance to the maintainers of a third party library *WITHOUT compromising our own product* it'd be worth it. Sadly it's here where SDL is a less than optimal solution.
Just as a recent example, until recently the entire Windows backend had no clue about Unicode, it was using the ANSI API for everything and many parts were hard coded to assume 8 bit characters. It was a non-trivial amount of work to change this.