Ideas for SDL 3 #3519
Comments
No more underscores between the namespace and functionality. This is essentially based off of the naming scheme proposed for SDL: libsdl-org/SDL#3519
|
Since I was the author of the proposal on the bugzilla but not able to edit this one, let's summarize and remove irrelevant stuff (the hard no to move to git is no longer valid). Stricter coding, naming style.For the moment there are high number of style issues in the API. Some symbols are Every functions that are tighed to a specific structure should: Be prefixed by its name: Getter and setters should be named as following:
Constructors and destructors should be named as following if applicable:
If objects are not meant to be dynamically allocated, the names "Init" and "Finish" or "Close" can also be used. Proper semantic versioning.SDL 2.0.9 version added sensor support, while it should be bugfix instead. The current versioning scheme makes too difficult to check what features were provided and when at a glance. What did 2.0.1 provided? What 2.0.2 provided? In the head of packagers, they feel like they are bugfixes while they've added new APIs! The Semantic Versioning is the most appropriate versioning scheme for libraries.
Removing useless platforms.
Fixing inconsistenciesIf we have structs, then functions should always operate on them. Since C99, compound literals makes life easier while passing temporaries to functions.
The color handling is sometimes in 4 ints, sometimes SDL_Color. Getting rid of dozens of buildsystems to unique one: CMake.There are just too many build systems in the tree and that is too complicated for users, developers and packagers. Also, having only one for a portable library that SDL is, makes difficult to merge all checks/operations in all build systems. Also, lots of people do not rely on the SDL CMake configuration package files provided as autoconf does not install them. Having CMake only will simplify the integration and maintainance. Use doxygen documentation to avoid outdated information on the wikiI've literally spent 3 hours to document the sensor API on the wiki. That's a big waste of time. SDL headers are already almost documented in doxygen, it should be completed with missing bits and the only source of truth. Changing something in one enum results in editing the wiki as well. Rename pkg-config filesThe SDL pkg-config file is Making addons first class citizen and built from the same source tree with proper namingThe SDL addons feel they are separate projects as they still do not have any public visibility from the libsdl.org website. At a glance, a newcomer don't even know these libraries exist. They have the same troubles as the above paragraphs (cmake, consistency, etc.). I propose the simple inclusion of these addons with a new naming scheme for them and a simpler API. Also, they will be available as separate shared/static libraries controlled at build time. Thus, people who don't need SDL_mixer or SDL_ttf can simply not build/link theme. SDL_ttf new APIEvery functions start with SDL_Font.
SDL_image new APIEvery function start with SDL_Image.
SDL_mixer new APIBasic functions start with SDL_Mixer.
Channel and groups functions
Chunk functions
Music functions
Effect functions
SDL_netTo my humble opinion, this library should be removed as they are many networking library in C including POSIX. |
|
Here are my thoughts... Stricter coding, naming style.Generally agreed. We'll need to create an sdl2-compat library similar to sdl12-compat that preserves the old ABI for older programs while continuing new development in sdl3 with a more consistent API. Proper semantic versioning.We'd have to look at how library versioning is done on Linux. We need to guarantee that older binaries continue to run with newer versions of SDL, and the current versioning system does that. The version is actually generated by using the scheme in autotools: and it turns out that this guarantees binary compatibility in the way that we need. In terms of knowing when functions have been added, we now include that information in the headers and wiki so it's easy to find. Removing useless platforms.WinRT is still used by the UWP code for Windows Store games and Xbox, so it will continue to be relevant. Fixing inconsistencies
We should review what compilers and platforms are still supported. I'm still occasionally surprised that people are still using platforms that require C89 code. But I agree we should be consistent here, with an eye toward the most efficient and easy to use interfaces. Getting rid of dozens of buildsystems to unique one: CMake.I think we should bite the bullet and just pick CMake over autotools. Maintaining two separate configuration and build systems is too high a tax, and enough people (and platform maintainers) are using CMake that it seems like the right choice for SDL 3. That said, we should still keep the Visual Studio and Xcode projects for people who are more comfortable using the IDE's. Use doxygen documentation to avoid outdated information on the wikiThis is already done. Ryan has created a bridge between the headers and wiki so each side is automatically updated by changes in the other side. Rename pkg-config files👍 Making addons first class citizen and built from the same source tree with proper namingThe problem here, and the reason why the SDL addons have lagged behind in terms of releases, is these depend on a lot of third party libraries that are time consuming to build and maintain in-tree. git submodules may make this easier though, so this is definitely worth reviewing. The ability to easily add modules to your project with CMake makes this much more viable in the future. I generally agree with the naming suggestions for the third party APIs above. SDL_netAgreed. There are lots more tools out there now than there were when this library was created. |
Well semantic versioning does not really care about ABI, it only cares about API in the sense that a program that uses a specific minor version may get new features but with never incompatibilities.
The C99 compound literals are for the user side, SDL does not need to have C99 support. This just means that if we take structures as argument the user can do: SDL_DoSomethingWithARectangle(&(const SDL_Rect){.w = 10 }));
CMake generates proper Visual Studio and Xcode projects. Visual Studio even has a nice integration.
We don't incorporate third party libraries. That's generally a very bad thing to do because of ABI incompatibilities (and there are too much systems and architectures). This just means that we conditionally add support to a feature if present. For example, if user selects MP3 support, then SDL_mixer will be linked against the system mad/mpg321 library. Nothing more :) Once SDL targets the 3 version, please write a ping here so that I can start massive refactoring :) |
Make SDL_main a header-only libRight now using SDL_main can be painful, especially with MinGW: There you have to link Lines 27 to 41 in 1bfefb5 I think this happens because main() (or WinMain() or whatever) being in a static lib (instead of a source file that gets compiled as part of the build, or a .o/.obj) seems to confuse MinGW, which otherwise would automagically link libmingw32.
Another (also Windows-specific) problem is that .lib files generated by MinGW don't work with modern MSVC versions ("module unsafe for SAFESEH"). For the SDL2.lib only used for linking the DLL it's not that bad, because it can relatively easily be generated from SDL2.dll (create a .def with mingw's These problems would vanish if SDL2main was a header-only lib that you just As a nice side-effect, it would make it clearer when it is used an when not: Furthermore, it would make it easier to copy the SDL_main implementation into your own source and adjust it to your needs. |
I like this idea. @icculus, what do you think? Is this something we can implement in 2.0.22? |
|
I like the idea but would keep this in the SDL 3 bucket. |
|
Another idea for SDL3:
|
|
IMPORTANT: We will also need sdl20-compat from the very beginning. |
|
BTW, are there plans for a SDL2.1 before SDL3? |
|
SDL3 is the next major ABI breaking revision - what we previously were calling SDL 2.1. |
|
So I'm just catching up on this, so I wanted to throw in my current opinions. I want to be clear that when suggesting big changes my instinct is to say no, and--as you can see from my "hard no" about GitHub--I don't make all the decisions and sometimes it turns out I'm proven wrong. Stricter coding, naming styleI agree that SDL2 is extremely inconsistent in this regard, and we should definitely clean that up for SDL3, but I do not think it has to be as rigid as SDL_SubsystemVerbSubject. Semantic versioningSDL versioning can change, but semantic versioning is deeply overrated in my opinion. We tend to never break even minor interfaces before we decide to change everything at once, and we do this less than once a decade in general. In the meantime, we add stuff all the time and constantly fix bugs and occasionally we bundle this up as production ready. We don't generally put out releases more than a few times a year. Please do not reply with how the semver philosophy should be applied to this. It's just dogma, as far as I'm concerned. Remove useless platformsEvery time I try to get rid of a platform or backend, someone pops up to say they still need it. For various backends, this is largely harmless, because they can be ignored and even bitrot without a serious cost to the project. But even things like Sony PSP and OS/2 have active users and maintainers. A lot of things would be hard to delete, is all I'm saying. Arts can definitely go, though. :) Build systemsI would love to drop to just CMake (or an equivalent, if there's a better option), but there is a value in telling people they can just double-click the Visual Studio project file and build. Even though CMake can generate vs project files, this adds friction for the average windows and Mac developer. Between CMake and autotools though, CMake sucks less and we frequently have issues where we have to fix problems in one or the other, so dumping autotools is okay with me. It might be interesting to find a way to automate this on Windows/Mac, so the user double clicks a small included .exe and it gets CMake installed if necessary and generates the project files. Use doxygen documentation to avoid outdated information on the wikiThis is done. Changes to Doxygen comments in the headers automatically generate Wiki changes now and vice-versa. It generates manpages now, too! This doesn't cover anything but functions...structs and stuff are not bridged, but this can change. Making addons first class citizen and built from the same source tree with proper naming100% no. Get rid of SDL_net100% yes. |
|
Here's an old Trello board about ideas for future improvements to SDL that got propped up at some point, I think to collect stuff that was mentioned around other places. Not all of it is still relevant (or was ever necessarily good)... https://trello.com/b/sXcrlXCD/sdl-wishlist ...but it's probably worth sifting through. I've made it read-only to prevent the discussion from migrating to there. |
|
I might have missed mention of it, but for an abi breaking revision i would love to see a more consistent access to platform-dependent things. The main thing that made me think about this was this issue over here (which, i realize, is another shameless bump, sorry x.x): #3360 The most use out of this would be in the rendering system - access window handles for video, texture and context access for the renderer. Where to draw draw the line though? |
|
I think the plan is to remove HOWEVER, icculus is working on a 3D API (see https://discourse.libsdl.org/t/future-3d-api/33485/23), and if I recall correctly, there were plans to allow interaction between that and SDL_Render (I guess SDL_Render would use the new 3D API under the hood). |
|
I created #3360 initially to think about an alternative to just removing stuff. Don't mind me, have a great day :D |
|
BTW, regarding that earlier post from @markand
Designing an API for compound literals + designated initializers hurts its usability IMO, especially for C++:
|
As I have mentioned, its just about adding consistency with what functions should take. Some functions at the moment use several |
|
Async rwops: #1374 |
|
High DPI consistency - most of these are assuming SDL will stick with DPI-scaled units for window position/size (which I personally prefer):
Some of these could be done before a theoretical SDL 3 because they don't all break or change APIs, but it's probably best to think of them all in concert for SDL 3 in any case. |
|
System notification API: #1932 |
|
Drag and drop improvements: #5292 |
|
Don't clamp IME input to fit in an event structure: #5363 |
|
Reconsider multiple audio device opens: #5485 |
|
Throwing this out there because it's something I consistently ran into while working on Wayland, and is a consistent pain point for other backends like X: The SDL_Window API spec should be modified to make all changes buffered, with a CommitWindowChanges call to push everything at once. This fixes the main problem we've been having lately, which is that the order of window calls can finally stop mattering and SDL can enforce consistent behavior without having to fight the OS as much. On top of being a pretty major bugfix (see the numerous issues for this, usually it's when modifying a window size after leaving fullscreen) it's also an optimization; Wayland for example has to commit the window surface every time a call is made, while in reality we shouldn't have to do it more than once (or twice if you count presentation) per frame. Right now compositors hate us for doing it like this, and when you actually look at the interaction at a low level it's easy to see why (see #4563). This is similar to the old SetVideoMode without forcing SetVideoMode - someone could make multiple CommitWindowChanges calls if they absolutely needed to, while still knowing the consequences of not optimizing the batch of changes. |
More or less, that's what I'm proposing, but GitHub Actions also has a cron-style interface, so we can just blast out a "build everything you can think of" on a once-a-day or whatever basis that's divorced from the smaller set of checks we want to see immediately and in-line. As for ignoring them: it runs in parallel to some degree, but it stops all currently-running builds if one of them fails, afaik, so I also want to avoid not knowing if Mac is working immediately because the PlayStation 2 port broke 100 commits ago. |
Modulo some name changes, you pretty much want the same thing between each version of SDL, and in the compat scenario, you only ever deal with one implementation...whereas with the dynamic API, you have two incompatible interfaces operating in parallel and might want to override them both. |
I'm going to write this here, and if it makes sense we can reference this in a new SDL_net issue, but let's not carry on discussion about this in this thread. I will say, upfront, that I expect we are going to be buried in SDL3 work, while still attempting to keep up maintenance on SDL2 while we do it, for the foreseeable future, so I just don't see an upgrade to SDL_net happening for a long time unless someone else steps up to do it. To answer this question: yes, everything uses BSD Sockets now, or WinSock, which is 95% BSD Sockets and the rest can be protected by a small The hairiest places are:
|
|
Okay, I think I've split out most relevant things to their own issues, thus ending this megathread. If you don't see your thing mentioned in a separate issue, above, then I either missed it, thought it was already fixed, thought it was being handled by an existing issue, or made an executive decision to say no. :) But I can't really stop you in that last case, so you should always feel welcome to open a new issue yourself if you feel strongly about it! This thread is being closed now, though, so don't dump any more ideas in here, or they risk being forgotten. Now that we're doing SDL3 for real, just go ahead and open a new issue. Thanks everyone! |
and others
This bug report was migrated from our old Bugzilla tracker.
Reported in version: don't know
Reported for operating system, platform: All, All
Comments on the original bug report:
On 2020-01-22 15:55:25 +0000, David Demelier wrote:
On 2020-01-23 02:56:03 +0000, Sam Lantinga wrote:
On 2020-03-23 22:53:39 +0000, wrote:
On 2020-03-24 01:04:30 +0000, Ryan C. Gordon wrote:
On 2020-03-24 01:15:27 +0000, wrote:
On 2020-03-24 03:32:52 +0000, Ryan C. Gordon wrote:
On 2020-03-24 08:15:06 +0000, David Demelier wrote:
On 2020-04-02 22:25:09 +0000, David Ludwig wrote:
On 2020-05-26 07:50:59 +0000, Jan Niklas Hasse wrote:
On 2020-11-28 11:36:22 +0000, Dominik Reichardt wrote:
On 2020-11-28 11:39:12 +0000, Jan Niklas Hasse wrote:
On 2020-11-28 11:44:23 +0000, Dominik Reichardt wrote:
On 2020-11-28 11:59:54 +0000, Jan Niklas Hasse wrote:
The text was updated successfully, but these errors were encountered: