>>529
Raylib is a single-header library, so I'm sure it'll play fine with your threaded and networked application. That said, neither of those are 'built-in'; you would need to provide your own. Sound, however, is very well supported, see 'module: raudio' on the cheat sheet: ht tps://www.raylib.com/cheatsheet/cheatsheet.html
As far as networking goes, no it's not included right now. See this thread about developing a networking module for Raylib and the solutions users came up in the meantime: ht tps://github.com/raysan5/raylib/issues/753 People seem to like enet: ht tps://github.com/zpl-c/enet ht tps://github.com/nxrighthere/ENet-CSharp Here's an example of using enet with Raylib: ht tps://github.com/JeffM2501/raylib_networking_example nbnet was also mentioned at the bottom but the link was dead there so: ht tps://github.com/nathhB/nbnet
Just gonna drop this here for everyone too - giant curated list of game development libraries: ht tps://github.com/Caerind/AwesomeCppGameDev World's your oyster, mates.
As for threading, CPP has had concurrency support since C++11, and using posix threads (pthread.h) should be supported by all platforms. The trick to threading, of course, is all about resource access, as long as you aren't trying to access a resource (something in RAM, the GPU, whatever) with two threads at once, you should be alright. So while trying to render a complex scene using two or more draw threads will absolutely fuck your shit up, using a thread to calculate updates to game state (pathfinding, line-of-sight, physics, sound, background resource loading, etc. while your main thread is going through all your draw lists, you should be alright. You also have to ask yourself, "Do I really need concurrency in my game?" Even toasters today have 3+ GHz processors pipelined miles deep. I guarantee you can see better than the 2-4x speedup of threading by just fixing your approach somewhere. Got 300 entities recalculating their pathfinding every frame and struggling to hit 60 FPS? List them up, and update 30 of them every frame, in round-robin fashion. Now you're updating everyone's path 10 times a second instead of 60 and your shit's 6x faster. Stuff like that. If you're even considering raylib for your project, I really wouldn't worry about threading. Look at the complexity and speed of games in the 386 to pentium 4 era and look at the processing power we've got today. You could absolutely make a Quake-like in Raylib if you wanted to. As long as you don't write your shit all retarded, you'll be alright. Here's a really basic threading example for raylib: ht tps://www.raylib.com/examples/core/loader.html?name=core_loading_thread