Mon Apr 15, 2019 12:51 am
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.
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".
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.
Mon Apr 15, 2019 8:47 am
Chris wrote:Sure, but given the number of applications that rely on SDL/similar, if it's a desired feature it won't be ignored. If you can't update your code to supply new hints for a new feature, you likely couldn't update your code to access the new feature directly either. So with the former, you may or may not get an automatic improvement with a library update, and with the latter, you definitely won't.
But more seriously, if it's a feature that a lot of applications need, they can't ignore it.
If so, it sounds like a serious bug that would be affecting not only those Doom source ports, but everything else that uses SDL for similar functionality, and should be a high priority for them to fix.
It's obviously not a problem with the platform's capabilities since Wine is using all the same facilities a native game could (in a less-than-efficient manner, even), but the developers of such games simply don't have the time or financial incentive to make their Linux-specific code as good as it could be.
Mon Apr 15, 2019 9:01 am
Graf Zahl wrote:It all depends. Yes, we have our own Windows backend, our own macOS backend and our own SDL backend.
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.