I have an SDL game that I have deployed on Steam. Currently I am deploying for Linux and Windows and plan to deploy for Mac later.
Recently when I deployed on Linux I noticed that the game wont run because SDL_mixer is missing. From what I understand Steam games should have access to SDL out of the box?
My Linux test machine has SDL2, SDL2_image and SDL2_ttf installed. Are these libraries installed automatically when Steam is installed?
Any ideas on why I’m missing SDL2_mixer on my Linux test machine?
My Linux distribution has only two objects
mygame (executable)
assets (graphics assets folder)
My Windows distrubution has:
mygame.exe (executable)
assets (graphics assets folder)
I’m using VS Code for both Linux and Windows. On Linux I’m building with g++ and on Windows with MingW64.
I’ve done a little research online and it sounds like dynamic linking is the best way to go. I’m still having trouble understanding the best/proper way to deploy my game on Steam and hope you may be able to provide some insights.
Some other questions I have:
Should I be using the steam-runtime to build? I’m still a little fuzzy on what the steam-runtime can offer.
Is it correct to be including all these DLL’s in the Windows deployment or is there a better way on Windows?
I haven’t done steam development yet, but looking at your list of included libs, I’m not seeing the shared object (.so) files for linux. (.dll) is Windows specific.
Either you will need to build SDL on a Linux machine, or link to whatever Steam provides. I’m assuming that Steam has some level of sand-boxing that prevents you from linking to the libs on the client’s machine?
You should also be able to find the *.so files in /usr/lib folder of your Linux system.
AFAIK no, Steam does not install SDL_Mixer. Yes, you should to link to the Steam runtime and use the Steam-provided version of SDL. Dunno if Steam provides their own build of SDL_Mixer (doubtful) but if not you’ll need to ship your own version of it.
Generally speaking, if you’re shipping something for Linux that isn’t packaged with/by the distribution, you don’t want to rely on the distribution libraries. They can be incredibly old, or may ship a new version that has regressions that blow up your app, and generally it’s not very user friendly to tell your users they need to go install some packages before they can play your game. Build and ship your own (they don’t have to be statically linked, either). If you’re building for Steam, use their build of something when available.
Simply supplying the .so files next to the executable in Linux doesn’t seem to work in the same way that it does in windows. In Linux it seems like it doesn’t use the current directory as a library path. I tried including the .so files as well as symlinks to the .so files.
I need to try and find some tutorials on how to either build or distribute the Linux version of the application.
I think I may need to use the steam-runtime. I’ll try doing some research here and see where I get.
You have to build your executable so the runtime linker looks in the same directory as the executable. I don’t know the linker options for doing this offhand.
I did see those linker options in a forum post somewhere for setting the current directory as the library directory, but I’m not sure that’s the best way as SDL is included with steam so I really shouldn’t have to include anything with my game on Linux.
find ~/.local/share/Steam/ -iname ‘libsdl*’
I see
libsdl2-mixer
libsdl2-net
libsdl2-image
libsdl2-ttf
libsdl2
So everything should be included already with the steam client.
Seems the problem was that I was still running Fedora 34. After updating to Fedora 36 the game started running as expected. So I think I’m good for now and can just go on and continue developing my game. I will try and learn more about the Steam Runtime though as well because I think building in the steam runtime is what is recommended for Linux development.