Steamworks API not working with MinGW

Has anyone had any luck using Steamworks API with SDL?

I’m working Eclipse with MinGW and I’m comfortable and familiar with it. But Steamworks requires Visual Studio, so, it won’t even compile under MinGW.

I’ve setup Visual C++ Tool Chain in Eclipse, but SDL won’t compile. I get the following error: SDL_platform.h(133): fatal error C1083: Cannot open include file: ‘winapifamily.h’. Before I spend days trying to solve this and further problems, I’d like to hear other people’s experiences with this?

Also, I believe I won’t be able to use the debugger in Eclipse if I use VC++?

Is the only option to install and use Visual Studio?

Thanks. I’m pretty desperate at this point. It shouldn’t be this difficult. Why can’t Steam support an industry standard compiler, rather than VC++?

Well, it’s Visual Studio that is the industry standard on Windows. If you want to use mingw you have to be prepared to do some extra work almost always when using external dependencies.

I meant ISO standard. VC++ is not standard C++, so it’s not compatible or portable. Steam has forced everyone to adopt a non-standard language. MinGW doesn’t require any extra work - it conforms to ISO standard C++ and works out of the box with anything else that also confirms to industry standard C++. Steam needs to at least supply an alternative library to their VC++ one.

They don’t need to do anything, and TBH this is the first time I heard about anyone using MinGW to build a (apparently?) commercial game for Windows.

Anyway, the problem here probably is that (afaik) there is no standard C++ ABI on Windows, and that MinGW and VC++ are (again, AFAIK) not ABI-compatible for C++.
A possible solution is a wrapper around the Steamworks SDK that provides a DLL with a plain-C interface that you can use.

A starting point for that might be Icculus’ steamshim: https://hg.icculus.org/icculus/steamshim/file/tip/README.txt
However that seems to be Linux/OSX-only at the time, so you’d first need to port it to Windows (and build the part that communicates with steamworks with VC++!).

There may be other more readily usable plain-C wrappers for Steamworks; Google returned the following:
https://github.com/rlabrecque/CSteamworks and https://github.com/addictgamer/steamworks-c-wrapper
I guess those will allow you to build a DLL with VC++ that has a plain-C interface.
You can then use/link that DLL in your MinGW code (in contrast to C++, the C ABI should be compatible)

Good luck!

Ok, maybe I was partially wrong, looks like MinGW at some point started being compatible with MSVC++: http://www.mingw.org/wiki/Interoperability_of_Libraries_Created_by_Different_Compiler_Brands and http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs look like mingw can indeed link against MSVC C++ libs.

However these links are about the “old” mingw, I couldn’t find anything about mingw-w64 - and the first link still mentions problems, so even if it’s possible to make this work, it will probably not be trivial, so maybe using a C wrapper still is the easiest way.

(Is there no Steamworks Support Forum? You’d probably be more likely to find people who already solved this problem there…)

Why shouldn’t MinGW be used to make a commercial game? What benefit is VC++ over MinGW?

I once ported Yamagi Quake2 to MSVC to debug an issue where MinGW-w64 binaries + gdb only gave me garbage information, possibly due to stack corruption - the MSVC binaries and VS debugger were a lot more helpful there. IIRC there wasn’t even really a stack corruption, so I can only assume that MinGWs debug information and/or gdb were buggy. (I wish I didn’t have to do that, we usually build with MinGW as well, partly because MSVC doesn’t support some C99 features like VLAs…)

Anyway, I didn’t say it shouldn’t be done, I said it’s unusual/rare (which might be a reason Valve doesn’t seem to support it directly).

So maybe let’s focus on the technical issue here instead of boring arguments for or against some particular compiler (or in what form Valve ships their libs - you should discuss that with them if needed).

Were the various links I provided helpful in some way?

One of the links talks about circumventing the linker errors, which will lead to a segfault. Other solutions involve parsing the headers, libs and dlls to convert them to MinGW, but this method got far too messy and kludgy and didn’t work for me. I did find a forum where people developing for Vive had found a working solution, but I didn’t understand it and it was only providing the Vive headers. Pretty much everyone on the private Steamworks developer forums are using Unity, or Unreal, which do all the Steamworks stuff for you, so they can’t help. I did look at the Steamworks Web API, which looks interesting and useful, but it require a lot of work to get working because it involves parsing json data and I’ve never done any Web API stuff before, so there’ll be a learning curve.

If you look at games such as FTL on Steam (http://store.steampowered.com/app/212680/FTL_Faster_Than_Light/), you’ll notice that to this day it still doesn’t have Steam Achievements, because they’re using MinGW and haven’t found a solution. So, Steam DO need to release a MinGW version of their API because (apparently?) there at a lot of commercial games being developed in MinGW and there needs to be a choice. If the SDL2 guys can give a choice, then it shouldn’t be too difficult for Valve.

Buyers of my Steam games are screaming at me for achievements and leaderboards, so I’m biting the bullet and installing Visual Studio now. Customers come first.

Thanks for your help.

I understand your frustration, but I feel like your are preaching to the choir here. You should direct your complaints to valve. Lots of indie games are probably developed with mingw nowadays, but I feel that people “in the industry” don’t really have visibility on this and just assume everyone uses visual studio like they do.

My projects usually compile on both VS and mingw with cmake, and I do my development mostly using mingw on clion. I remember also having similar problems using blender in the past when many tools/libraries/engines just assumed everyone is using 3d max, but things have been getting better every year.

Anyways, I would recommend going with the C wrapper approach, so you can still use mingw for your game development if that’s what you like.

1 Like