Compiling Chocolate Doom with Visual Studio: a simple-ish guide

[Linguica]

I recently reinstalled Windows and I had to go through the rigamarole of getting everything set up to hack on the Doom source again. I figured as long as I was going through all the steps, I should record them, so that source hacking nubs can set themselves up with a clean version of Chocolate Doom, without using *ptuh* Codeblocks...

1. For this tutorial, I will use the (currently) most recent version of Visual Studio Express. (Everything should work the same for VS Community Edition.) You can download Microsoft Visual Studio Express 2013 for Windows Desktop at https://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx . You will need a Microsoft account in order to download it. Once you download it and run the installer, it will take approximately seventeen years to install and use a ton of disk space, just because. (You can probably largely adapt this for older editions of Visual Studio Express too. Here is a direct link to the Visual Studio Express 2010 SP1 ISO, which you can mount with any number of tools, or unzip with 7zip, or what have you.)
   
   
2. While you wait, go to the Chocolate Doom Github: https://github.com/chocolate-doom/chocolate-doom . Click "Download ZIP". Unzip the file to wherever you want the files to go.
   
   
3. Next, go to the normal Chocolate Doom download page at http://www.chocolate-doom.org/wiki/index.php/Downloads and download the normal Windows binary package.
   
   
4. Next while we wait, you should download the SDL libraries you will need. Go to https://www.libsdl.org/download-1.2.php and download SDL-devel-1.2.15-VC.zip (Visual C++). Unzip this file and put the directory somewhere you won't disturb it. I put the directory in C:\Program Files (x86)\SDL.
   
   
5. Next, go to https://www.libsdl.org/projects/SDL_net/release-1.2.html and download SDL_net-devel-1.2.8-VC.zip. Unzip the file into the same directory you put the previous one.
   
   
6. Next, go to https://www.libsdl.org/projects/SDL_image/release-1.2.html and do the same thing with SDL_image-devel-1.2.12-VC.zip. This one is not strictly necessary for Chocolate Doom, but you should download it anyway in case you want to try and compile PrBoom later, since you'll need it for that.
   
   
7. Finally, go to https://www.libsdl.org/projects/SDL_mixer/release-1.2.html and do the same thing with SDL_mixer-devel-1.2.12-VC.zip.
   
   
8. Now that you have downloaded and unzipped these four files, let's make life a little easier. In the /SDL/ directory, make a new "include" and "lib" directory. Then go into each of the four SDL subdirectories and go into /include/ or /lib/x86/ in turn, and copy the files within into the main directory of the same type. What we are doing here is accumulating all four sets of include files and library files into one directory to make life a little easier later. It should look more or less like this:
   
   
   
   
9. Hopefully by now MSVC Express will have finished installing. Open the program and do FILE -> Open Project. Navigate to your Chocolate Doom source directory, then go to the msvc subdirectory. Open doom.vcproj.
   
   
10. The software will probably tell you it needs to upgrade the files to be compatible. Do so.
    
    
11. Once it finishes, and you open the project, it will take a minute to parse all the files. Once it's done you should be looking at something like this:
    
    
    
    
12. Click on "Doom" in the list on the right, then in the menu, go to PROJECT -> Properties.
    
    
    
    
13. First, click on "Configuration Manager" and uncheck everything but Doom, libopl, libpcsound, and libtextscreen.
    
    
    
    
14. Next, make sure "VC++ Directories" is selected on the left, then click on "Include Directories" and click on the small dropdown arrow. Click on "Edit..."
    
    
    
    
15. In the new window, click on the little "New Folder" icon at the top, then on the small "..." icon. Navigate to the /SDL/include/ you populated before and add it.
    
    
    
    
16. Click OK and then go down two slots to "Library Directories". Do the same thing, adding the /SDL/lib/ directory you already populated.
    
    
17. Now you need to do the same thing to add the /include/ and /lib/ directories to the properties for each of the projects of libopl, libpcsound, and libtextscreen in the main sidebar. Note that you can shift-click to select multiple projects at once and set the properties for them all in one go!
    
    
18. Now that this is done, you can finally compile! With the "Doom" project selected, go to BUILD -> Build Solution. You'll get a bunch of warning messages, but (hopefully) 0 errors.
    
    
19. Now go to the /bin/ directory and you should see the fruit of your labor:
    
    
    
    
20. You're almost done, but not quite! To play this EXE, you need the DLLs from the normal distribution. Open the normal binary package and copy over the three DLLs from the normal Chocolate Doom binary download.
    
    
21. Run chocolate-doom-dbg.exe. If it works, hooray! You're ready to start poking around in the source code and building your own versions!
    

[VGA]

MS Visual Studio 2013 Community Edition is where it's at.

[Jon]

Cool.

I was half-wondering whether to look at revamping the c-d windows build instructions when my current project ends. That wasn't the direction I was thinking, but it probably makes a lot of sense. The latest Visual Studio has a Linux and Mac version, so if someone created a VS project file (did you keep yours, Linguica?) there's some chance it can be updated/tested by people who don't regularly use/have access to Windows; and might be worth committing. (IMHO)

[david_a]

Jon said:

The latest Visual Studio has a Linux and Mac version

No, it doesn't. Visual Studio Code is fancy text editor (like GitHub's Atom, which it's based on) that is primarily intended for web development where "compiling" isn't really a thing. It solves completely different needs than the full Visual Studio. You can open C/C++ files in it, but I don't think it can open projects/solutions and there's no hook for invoking a compiler (although you can probably add one since it's very extensible). Visual Studio's UI is written in WPF so it will sadly never see a Mac/Linux port (as much as I would like it to, so that I can throw Xamarin Studio in the trash where it belongs).

About Linguica's guide:
1) Why did you download the source as a zip instead of cloning the repository?
2) Is the missing file a flat-out mistake? If so, did you submit a patch/pull request for it?
3) What are the DLLs you need from the binary download and where do they originally come from?

I'll try to follow the guide soon for more feedback :) I'm primarily a C# developer so the C/C++ build system feels like an archaic nightmare to me.

[Jon]

david_a said:

No, it doesn't.

Oh, my mistake, thanks for clarifying.

I guess the best strategy might well be to have a big ZIP somewhere of the necessary bits of MinGW + SDL all arranged properly. Such a thing would actually be useful for quite a lot of ports.

[Linguica]

david_a said:

1) Why did you download the source as a zip instead of cloning the repository?

Not everyone wants to use Git, or knows how.

[kb1]

Linguica said:

Not everyone wants to use Git, or knows how.

...including me.
Thanks so much for this tutorial. Sometimes it's quite intimidating to try to compile someone else's code, especially if it was primarily developed for a different environment.

This is very helpful, indeed. Thanks again!

I don't have web access at home, so I had to run the MS VS 2012 installer from a command prompt, with the "/Layout" switch to get it to create a full proper install that I can place onto a USB thumb drive, and install at home. Just incase anyone else wants to do this, here's what the command-line looks like:

wdexpress_full /Layout

I'll let you know if it worked later.

[fabian]

Linguica said:

Next, go to https://www.libsdl.org/projects/SDL_image/release-1.2.html and do the same thing with SDL_image-devel-1.2.12-VC.zip.

You don't need SDL_image for Choco.

[Linguica]

fabian said:

You don't need SDL_image for Choco.

True, but you need it for prboom-plus, which is a logical next step for a tutorial...

[Gez]

Why do you make unchecking Heretic, Hexen, and Strife a mandatory part of the tutorial? What if people want to compile them too?

[jmickle66666666]

Invaluable guide, thank you!

[Linguica]

Gez said:

Why do you make unchecking Heretic, Hexen, and Strife a mandatory part of the tutorial? What if people want to compile them too?

Because the title of the thread is "compiling Chocolate Doom" duh

[Marscaleb]

I wound up getting 54 errors. They read as:
error C1083: Cannot open include file: 'SDL.h': No such file or directory

and about half of them them say the missing file is "SDL_endian.h" and one says "SDL_types.h"

I don't see these among the files I was told to download, so I'm not sure what I did wrong.

[Linguica]

Sounds like you didn't include all the SDL files correctly. Go through the steps for that part and make sure you did all the include and library directories for SDL, SDL-net, and SDL-mixer for each of the four necessary projects.

[Marscaleb]

No, none of those .h files are in my "include" directory. But I found my mistake; I downloaded the SDL runtime library and not the development library.

So now I copied over the missing files and built it again, and I got 19 errors for unresolved external symbols. But I think these are because I'm trying to build crispy doom, so I'll post about it on that thread.
Thank you!

[vadrig4r]

Thanks for the brilliant guide, Linguica. Works perfectly on VS2013. For anyone trying to compile on VS2015 Release Candidate 14.0.22823.1 you may find yourself unable to do so.

I encountered two linker errors:

unresolved external symbol __imp__fprintf
unresolved external symbol __imp____iob_func

I did a bit of digging and found it related to VS2015 deprecating stderror for the first. The second has me stumped and is beyond my capability to fix; I just thought I'd throw this out there in case anyone was interested and/or wanted to have a go themselves.

It seems according to http://stackoverflow.com/a/30367186 it might be fixed by recompiling SDL. If I have a go I'll update with more info.

[Marscaleb]

Ahh... I found a problem. When I try running the exe I built in Windows XP, I get a message "(filename) is not a valid Win32 application."

It works in Windows 7, but I'm gonna need it working on these older XP machines if I'm gonna run a network game. :P

[Graf Zahl]

You get that when building with the standard toolset which is not XP compatible. You should be able to change that in the project properties under General->Platform Toolset.

[Patrol1985]

Big thanks for this tutorial Linguica!

I suggest stickying it - it's a good source of information for compiling in general.

[vadrig4r]

vadrig4r said:

Thanks for the brilliant guide, Linguica. Works perfectly on VS2013. For anyone trying to compile on VS2015 Release Candidate 14.0.22823.1 you may find yourself unable to do so.

I encountered two linker errors:

unresolved external symbol __imp__fprintf
unresolved external symbol __imp____iob_func

I did a bit of digging and found it related to VS2015 deprecating stderror for the first. The second has me stumped and is beyond my capability to fix; I just thought I'd throw this out there in case anyone was interested and/or wanted to have a go themselves.

It seems according to http://stackoverflow.com/a/30367186 it might be fixed by recompiling SDL. If I have a go I'll update with more info.

I figured it out, you just have to change the platform toolset to Visual Studio 2012:

1. Make sure to grab the latest source code from https://github.com/chocolate-doom/chocolate-doom as it includes both a fix for compiling on VS2015 and now correctly includes deh_bexstr.c so you don't have to add it manually (cheers Ling!).
2. After loading doom.vcproj, select all of the projects in the solution explorer pane (e.g. shift click Doom, libopl, libpcsound, libtextscreen, libsetup) right click any of them and select 'Properties'.
3. Under 'Configuration Properties' > 'General', change 'Platform Toolset' from 'Visual Studio 2015 (v140)' to 'Visual Studio 2012 (v110)'
4. That should be it! Build as normal.

A couple of things I found useful, if you're happy with your code changes and don't need the console you can disable it:

Select the project corresponding to an executable (e.g. 'Doom') right click and select 'Properties', navigate to 'Configuration Properties' > 'Linker' > 'System' and in the right pane under 'Subsystem' change the dropdown from 'CONSOLE (/SUBSYSTEM:CONSOLE)' to 'WINDOWS (/SUBSYSTEM:WINDOWS)'.

If for a similar reason you don't need the .pdb file:

Right click Doom and select 'Properties', click 'Configuration Manager' in the top right, change the 'Active Solution Configuration' from Debug to release. Make sure to re/uncheck all the boxes for the projects that you do/don't want to build. You will also need to readd the include/library directories and update any other project settings you need (such as the above Linker setting).

I am by no means an expert on VS/Windows programming environments so if something is wrong please correct it, these were just the steps I went through in order to compile a functional and complete Chocolate Doom and hopefully someone will find them helpful.

[GooberMan]

vadrig4r said:

you just have to change the platform toolset to Visual Studio 2012

You're on the right track to understanding there. The problem you're having is that the binaries provided from the SDL website are not compatible with your shiny new VS2015 compiler. You can also solve this problem by downloading the source for the various packages you need and recompiling that for 2015, and thus get all the advantages that come with the 2015 compiler. To save you the trouble, I've gone and done it for you. If anyone else gets VS2015 now that it has launched and doesn't want to recompile SDL, download this and copy the included files over the ones you already have thanks to the instructions specified above. If you are running on an older version of Visual Studio, do not do this.

I also recommend, if you're on VS2015 (EDIT: well, any version after and including 2012 actually), using Property Sheets instead of the specified steps of adding include folders manually and copying binaries to locations manually. Property Sheets are the Visual Studio team's method of dealing with Windows not having a sane library setup like Unix (and alike) systems do. They're a single file that any project can include which tells your project where it can find whatever it wants.

I have a few set up here for SDL, SDL_Mixer, and SDL_Net. These property sheets do two things - automatically link up the necessary folders for the include and lib paths; and copy over any required DLLs to the folder where all the Chocolate executables are output. Handy. I still need to do a tiny bit of work to get around some MS bullshit (the nature of the custom build step I do means it always tries to copy the DLLs around for whatever project is being built), but they're quite functional right now.

The first is to actually add them to each of the projects that Chocolate Doom uses. This is achieved by going to the Property Manager tab in your solution explorer pane, right clicking on each project in turn, and selecting "Add Existing Property Sheet..." You can't select all three at once unfortunately, so add them one by one.



Once you've slogged through all that, you'll need to modify the properties of each property sheet to point to where you've put your SDL files.



Inside each property sheet I have a macro that refers to the path for that one. Update it to your local location.



And voila! Compile, and all necessary binary files to run Chocolate Doom will be found in the bin folder.

[vadrig4r]

Just what I was looking for, much appreciated! I had tried to muddle with property sheets but wasn't sure where to begin. Thanks for the clear explanation Goober.

[Marscaleb]

Graf Zahl said:

You get that when building with the standard toolset which is not XP compatible. You should be able to change that in the project properties under General->Platform Toolset.

Okay, I changed the platform toolset to "Visual Studio 2013 - Windows XP (v120_xp)" (My only other option was Windows Phone 8.0)

However, when I run it in XP, now it instantly gives me the error:
"This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

It still runs in windows 7 just fine, but more than half of the computers I am trying to use run windows XP.