Archive for the ‘Tutorials’ Category

Taming Visual Studio

March 3rd, 2010

This is a guide to setting up Visual Studio to make use a folder structure that is flexible and portable across multiple machines. It is intended for students, which is why no templates are included. After all, you are supposed to understand what each of the settings do!

Stay Away!

A lot of SDKs have tutorials and guides on installation, and advise that you make changes from the Tools > Options  screen as shown here. Don’t do it! What this does is make global changes to Visual Studio so that all your projects will use the same copy of the SDK. This means that you will find it difficult to use different versions of the SDK on different projects on the same computer. Also, if you pass your code to anybody else, they will need to get a copy of the exact same version of the library you are using and install it on their machines in a similar way in order to compile your code. The only SDK where it is permissible to touch this menu at all is DirectX, and that is because it is installed in an anal OS-monopolistic fashion. For anything else, follow the procedure below.

Our target is to get a working folder structure something like what follows. The bin folder will contain your executables. The lib folder will contain all your SDKs. The obj folder will contain all your object files so they may be discarded later. The project folders will contain the source code and project files of the various projects you have in the solution. This allows you to distribute your work in the following ways:

  • For end users, just give them a copy of the bin folder. That is all they need to run the program.
  • For source code inspection, just give them the project folder(s). Useful if you have quick questions on code snippets.
  • For distributing your source code, delete the obj folder and the intellisense file, and send the rest. This will ensure the end user can compile a copy of their own. This is what I expect to be submitted to me for assignments.

Creating a new project

So let’s get started. First thing is to create a new project from the File > New > Project menu. This will give you a choice of various types of projects to create. What you want to create is either a Win32 Console Application, or a Win32 Project. The Console App will provide you with a DOS box that you can cout to at whim. The main entry point for this would be main(). The Win32 project, on the other hand, makes a standard windows application without any console (unless you hack it in). The main entry point for this would be WinMain(). Make sure to tick the “Create directory for solution” checkbox.

newproj2

After you fill in a suitable name for the project and click OK, you will come to this screen. Do not Finish immediately. Instead click on Application Settings. The top 4 options lets you change your mind and build a console app or Win32 project or even a library… talk about redundancy. In the checkbox below however, you want to tick “Create Empty Project”. If you do not do this, Visual Studio will create a lot of junk for you that you will need to clear out later. After you are done, click Finish.

Once you are done, the project will be created. I personally like to delete the “Header”, “Source” and “Resource” folders so I can implement my own structure, but that is up to your preference. What you must do, is add a blank .cpp file to your project. It doesn’t matter what you call it or what’s in it. What this does is tell Visual Studio that this is indeed a C++ project, so it will show you all the relevant C++ options. Never mind that the application I installed was Visual C++ Express. After you have done that, go to Project > Properties to configure your project.

ProjSet1

The first thing you should do here, change the configuration to “All Configurations” so that you affect both the release and debug builds. Next, expand “Configuration Properties” on the left, and select the “General” category. Here you will change the output folders, to comply with the specifications we have above. These are the changes I made:

  • Output Directory, this is where all the exe files are made. Set it to $(SolutionDir)bin
  • Intermediate Directory, this is where all the obj files are made. Set it to $(SolutionDir)obj/$(ProjectName)/$(ConfigurationName)
  • Character Set, this changes all your strings to wide character strings. For game projects, you really shouldn’t be depending on the compiler for implementing unicode anyway. So set it to “Not Set”.

ProjsSet2

After that, click on the “Debug” category. Here, there is only one change to make. However, this setting needs to be set up for every single computer you move the project to. This is because Microsoft, in their infinite wisdom, decided that this particular setting should be personalized to each user. So don’t forget this every time you copy the project from one computer to another.

  • Working Directory, this is where your application will launch from when run from Visual Studio. Set it to $(OutputDir)

Include Folders

Next, click on the C/C++ category. If you do not see the same screen as in the screenshot, expand it out and click on general. Here, you will only change one setting, which is the “Additional Include Directories”. You will set this up to point at the include folder of whichever SDK(s) you are using. Multiple folders can be included by separating them with a “;”. Alternatively, doubleclick on the box and you can browse to each of the individual folders. Make sure that all your folders are set up relative to your Solution folder. This will ensure that your project, when copied over, will still be able to find the include files it needs. This means that every single one of the entries here should begin with $(SolutionDir)lib/

Examples:

  • $(SolutionDir)lib/ogre/include
  • $(SolutionDir)lib/hge/include

Linker Options

Next, expand out “Linker” and click on “General”, which is just under it. Here, just like the include folders, you will tell Visual studio where all the lib folders are by changing the entry “Additional Libarary Directories”. The setup is exactly the same. All entries are seperated by “;”. Examples:

  • $(SolutionDir)lib/ogre/lib
  • $(SolutionDir)lib/hge/lib/vc

Still on the same tab, the next bit is tricky. First, you will want to set the configuration to Debug, so that you only affect the debug build. It may prompt you to save settings, which you should agree to.  After that, change the “Output File” from “$(OutDir)\$(ProjectName).exe” to “$(OutDir)\$(ProjectName)_d.exe”. After that, apply your changes and set the configuration back to “All Configurations”. What this does is make sure that all your debug builds have a “_d” at the end of the exe names, so you can readily identify if your binaries are debug or release.

Additional Libraries

Next, still under “Linker”, switch to the next subcategory, “Input”.  Here, under “Additional Dependencies”, you will list down the .lib files that your SDK requires you to link into your project. These, in a great show of consistency, are not separated by a “;” like everything else, but are instead separated by a single space. Once you have added those in, you are done with project settings and can click OK. Your project is all set up… almost.

Do not forget to copy an .dll files that your SDKs might need into your bin folder. Also, if you need to include any additional assets in your project like artwork or sounds, the bin folder is where it’s all at. That is your base. And that… is all!

Posted in Tutorials | Comments (0)