[REQUEST] Merge SDL_Net into SDL

SDL Development
1

Hi all.
With the functionality provided by the main SDL library, it is possible to rewrite your own mixer (SDL_Mixer), font parser (SDL_Ttf) and image processor (SDL_Image) if you were so inclined without writing any platform specific code. However, to use the capabilities of your network card, you would have to introduce platform specific code or use SDL_Net or some other networking library.

As a result, I believe it would make SDL a more complete platform layer if you were given networking capabilities out of the box. Furthermore, it would be nice to not have to write any platform specific code or introduce other libraries (even if the networking code is relatively trivial). Ultimately, I was wondering if it would be possible to merge the SDL_Net library into the main SDL code base.

Thanks.

1 Like
2

This sounds like something I would like too. The SDL_Net library hasn’t been updated in a while. It has no CMakelists.txt, meaning you have to download msys2 or cygwin or some other unnecessarily large package just to compile it on windows. It would be nice to just have base install of mingw-w64, e.g. gcc, make and gdb to compile it.

3

I’d advice against this generally, because:

  • Many games will absolutely not need any network calls. It’s good to keep dependencies (including an external dependencies that SDL_net may bring with it, if any) to a minimum.

  • Different platforms need to handle networking differently. For example, on mobile, most calls are async and threaded, and how those two inter-operate is very much language and platform-specific. Just like having SDL_image/ttf/mixer as separate libraries gives you versatility with minimal cost, so does having SDL_net separately.

  • Including SDL_net into SDL might come with additional permissions by default on Android and iOS, which are a big flag. We are now at zero permissions for both platforms, which is absolutely perfect.

  • The US and other governments requires additional, yearly paperwork for apps distributed that use network. Although this is, I think, based on whether you actually use it, not whether you could, the case is much simpler to make if there’s just no code in the app that could potentially do any networking (that is, no networking libraries linked).

Alex

4

Hi Alex, thanks for your reply. A few points on what you said:

  • DEPENDENCIES: I agree most games will not require networking. However in this modern age, I believe a network card is very much part of a platform layer (the media layer if you will). Furthermore, in regards to external dependencies, Windows/Mac/Linux/iOS/Android all ship with some form of networking library that SDL could link to out of the box. In this case, in a time where storage size is relatively plentiful, wouldn’t the increase in size to SDL be negligible? So I don’t really see the issue there (not sure for other platforms).
  • PLATFORMS HANDLING NETWORKING DIFFERENTLY: I’m not an expert here, so correct me if I’m wrong, but if the SDL_Net library already exists to inter-operate with SDL, why can’t it be merged?
  • PERMISSIONS: If networking brings extra permissions on mobile, I can see this as a valid reason for keeping the two separate for mobile, but not for desktop platforms, e.g. Windows/MacOS/Linux.
  • PAPERWORK FOR NETWORKED APPS: I can see this as a valid reason for keeping the two separate. Perhaps a simple -DSDL_WITH_NETWORKING in the ‘CMakeLists.txt’ would give users the flexibility to compile with networking, but others can just download the pre-compiled binaries with no networking.

If nothing else, it would nice to have a ‘CMakeLists.txt’ for the SDL_Net library.

Thanks again for your input.

1 Like
5

Hi,

Thanks for taking the time to answer :slight_smile:

  • DEPENDENCIES:

    • I would not consider networking part of the media layer necessarily, but this is more my opinion than a claim or fact.

    • Adding dependencies also increases the complexity of the project, for developers and for users. Currently, the complexity of the ecosystem is so high that having a smooth experience with any build tools and libraries, no matter how well they are built, is very, very hard. We don’t manage this project, so others probably know best when it comes to SDL2, but generally managing these kinds of open source projects seems very hard and the reward very low.

      Currently, on my development machine, with the latest xcode, SDL2 results in over 400 warnings from the compiler. Before we increase the complexity, maybe we can help both maintainers and users to have a smoother experience with the pieces that are already there.

  • PLATFORMS HANDLING NETWORKING DIFFERENTLY: I’m not saying it can’t. I’m just saying that, depending on the language and platform, you may not want to use the networking facilities that SDL2 provides. Networking has become a bit more platform-specific because of how particular mobile is, and concurrency, which is now frequent also on mobile platforms, is very language-specific. The two go hand-in-hand these days (but threads are already in SDL2).

  • PERMISSIONS/PAPERWORK: If we can disable networking easily by removing SDL_WITH_NETWORKING from the compilation flags, then it seems like a reasonable middle point.

I would still argue that, in the long run, the point about complexity is going to matter a lot, but only the maintainers know how much effort it is taking and where they want to go.

Best,

Alex

EDIT: I made a mistake and listed over 600 warnings when it’s currently 442. My bad. I though I had seen 600 listed, perhaps in an earlier build, but the current count is significantly lower.

6

Yes, but what dependencies exactly? I link with SDL_net and I’m not aware that it has created any additional dependencies, on any of the platforms I build for (Windows, MacOS, Linux, Android, iOS).

7

I think you are right. My bad.

Adding SDL_net would bring with it the complexity of SDL_net itself.