dpJudas wrote:There's no guarantee SDL deals with that as the new best practice<tm> may rely on information not available to SDL without additional hints.
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.
I don't like abstraction libraries mainly because as soon as someone didn't bother adding a feature to the abstraction I'm more or less fucked. For example, recently the lazy folks at Qt didn't bother supporting proper frameless (main) windows. As a result, I cannot make a visual style that follows the general trend of the Windows platform.
Well, even Microsoft has a hard time following the general trend of Windows' visual style.
But more seriously, if it's a feature that a lot of applications need, they can't ignore it. Don't get me wrong, if there's something you actually need that a platform-independent solution doesn't provide, it's totally understandable that you'd do it "manually". If enough developers are willing and able to avoid Qt for not providing what they need, it would be a kick in the pants for the Qt folks to find a way to provide it.
Some of the users on Doomworld are complaining the software renderer of their source ports are stuttering - what if that's caused by SDL? If so they are game over.
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. But to turn that around, what if that stuttering is caused by developers using X directly, and not knowing how to use X correctly because their preferred/only dev system is Windows, or they don't have the time to work on the non-Windows code? No amount of improvements made to SDL will fix code that doesn't use it.
I actually find it interesting that even today, there are some games with native Linux ports that you actually get better performance when running the Windows version under Wine. 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. So a way to avoid that problem would be writing as little Linux-specific code as possible to begin with (an SDL/GLFW/SFML/whatever backend that's only used on Linux I'd still consider to be Linux-specific, since most developer attention will be with code used on Windows).
There are situations where I don't have the resources to write the proper platform implementation and therefore have to rely on such libraries, but ultimately I only do this if I have no other choice.
I generally look at it from the other direction. There are situations where I will write platform-dependent code because I have no choice to get what I need, but I first look to platform-independent solutions where possible.
[quote="dpJudas"]There's no guarantee SDL deals with that as the new best practice<tm> may rely on information not available to SDL without additional hints.[/quote]
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.
[quote]I don't like abstraction libraries mainly because as soon as someone didn't bother adding a feature to the abstraction I'm more or less fucked. For example, recently the lazy folks at Qt didn't bother supporting proper frameless (main) windows. As a result, I cannot make a visual style that follows the general trend of the Windows platform.[/quote]
Well, even Microsoft has a hard time following the general trend of Windows' visual style. :P But more seriously, if it's a feature that a lot of applications need, they can't ignore it. Don't get me wrong, if there's something you actually need that a platform-independent solution doesn't provide, it's totally understandable that you'd do it "manually". If enough developers are willing and able to avoid Qt for not providing what they need, it would be a kick in the pants for the Qt folks to find a way to provide it.
[quote]Some of the users on Doomworld are complaining the software renderer of their source ports are stuttering - what if that's caused by SDL? If so they are game over.[/quote]
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. But to turn that around, what if that stuttering is caused by developers using X directly, and not knowing how to use X correctly because their preferred/only dev system is Windows, or they don't have the time to work on the non-Windows code? No amount of improvements made to SDL will fix code that doesn't use it.
I actually find it interesting that even today, there are some games with native Linux ports that you actually get better performance when running the Windows version under Wine. 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. So a way to avoid that problem would be writing as little Linux-specific code as possible to begin with (an SDL/GLFW/SFML/whatever backend that's only used on Linux I'd still consider to be Linux-specific, since most developer attention will be with code used on Windows).
[quote]There are situations where I don't have the resources to write the proper platform implementation and therefore have to rely on such libraries, but ultimately I only do this if I have no other choice.[/quote]
I generally look at it from the other direction. There are situations where I will write platform-dependent code because I have no choice to get what I need, but I first look to platform-independent solutions where possible.