You have some good points there, RedBreadcat. Let me comment on a few of the troubles that you've encountered.
-Download physfs and cmake. Use cmake on physfs and you'll get a bunch of files in a folder. You want to include "physfs.lib" into your project. None of the other files matter, I think. CMake shouldn't be needed yet, at least until Amarth gets the CMake build file done. As for other required libraries, I simply had a look at the error messages and found the need to install and link with physfs. In a linux distribution, installing such things is often straightforward with the use of a package manager. Adding the link would then be as simple as adding the -lphysfs flag to GCC. There are different approaches in Visual Studio for the linking part. The other required libraries such as SDL were found the same way.
-You need SDL 1.2. Not 2.0! You'll also need SDL_image and SDL_mixer, both v1.2. Include all the libs, header files, and make sure the DLLs are in your working directoryMy hunch is that SDL 2 wasn't stable back when Amarth ported the game. So yeah, that's required. Switching to SDL 2 could bring a few advantages, but I wouldn't prioritize the migration.
-Visual Studio will complain about fopen, sprintf and other things. It'll want fopen_s and similar instead. I went through the effort of replacing all that stuff, but it'll be easier just Google "_crt_secure_no_warnings" and follow the instructions from there.It's true that Microsoft made its own bits of strangeness in their C++ headers. Yeah, forcing the compiler to allow that should be fine. We could also make a macro for each of those functions, if that really becomes important.
-For some reason I got lots of complaints about libstdc++-6.dll, libgcc_s_dw2-1.dll and other stuff. Just download them and stick them with the rest of the DLLs. There's probably a smarter way to resolve this >_>Curious. I wonder if that can be fixed by making a static link to the standard C++ library, rather than a dynamic link.
-You need to include opengl32.lib and glu32.lib along with the other libs. Don't worry, these come with your graphics drivers (I think), and the compiler will find them for you. No need to have them in your project's directory.That's OpenGL all right. Open Notrium uses that, so you have to add those to the linking process.
-Visual Studio's debug working directory conflicts with physfs. You see, when you debug the program it THINKS it's running in the solution directory. So, all the file access and relative paths go through there. However, the actual executable is in YourSolutionDirHere\debug. The problem is that the program uses physfs to load its files, and physfs is clever enough to know the TRUE location of the executable. Therefore, your texture, data, etc folders need to be in YourSolutionDirHere\debug. You also need to put all of SDL's DLLs in there. And you also need to set the debug working directory to $(SolutionDir)\debug. This took a great deal of suffering, trial and error to discover.Well, regardless of what physfs is doing, you need the extra resource files of the game in order to make it work.
-I was getting errors with all the max() and min() functions not actually existing. Apparently they actually need to be fmax() and fmin(). I have no idea how this could happen, given that such functions were from a standard library.The max and min functions actually do exist, but in the <algorithm> header. See that "main.h" includes <algorithm> rather than <cmath>. The Visual C++ compiler seems to know it too...
The other half is just C++ being a really old technology. We can move to C++11, which makes the language feel much easier to play with.
Edited 5 years ago