A Solution file (*.sln) is an all encompassing file that contains one or more Visual Studio projects within it.

A Project file (*.vcproj) contains all the files (source, headers, resources, etc.) needed to produce an application executable (*.exe), statically linked library (*.lib), or dynamically linked library (*.dll).

One of the main ideas behind the solution file is that it allows developers to set project dependencies during the build process. This means that if you have an application project that depends upon a static library project, you can set the static library as a build dependency for the application and Visual Studio will make sure that the static library gets built before the application during a solution build.

This is perfect for keeping the individual game engine modules independent of each other. For example, you can set up a Graphics solution (Graphics.sln) with the functionality in a static library (Graphics.lib) built by one project (GraphicsLib.vcproj) and a test / prototyping application (TestGraphics.exe) built by another project (TestGraphics.vcproj).

As for the project file, this is where all the compiler options are held. This makes sense because we want our compiler configurations to be set on a per library or application basis.

For our purposes, there are two Build Configurations we need to be aware of and understand:
Debug and Release.

The Debug build should be used as much as possible during development. This will be unoptimized and include a special #define symbol: _DEBUG that will affect the speed of standard functions, including: malloc(), calloc(), realloc(), free(), and assert().

To run the Debug build from within the IDE, make sure that the build configuration is set to Debug and press the blue "play" button or F5. This will launch the application in a new window (or windows if you have multiple) and start up the debugger running behind it. Note that this will launch the current StartUp Project.

The StartUp Project is the project whose name is bolded in the Solution Explorer (see the Graphics solution example above). If you attempt to run a project that is not an Application (.exe) type, you will get a dialog asking you for an executable to run; just hit cancel and select the correct StartUp project by right clicking on the project name and selecting "Set as StartUp Project" from the popup menu.

The Release build should be used to test a runnable executable from outside the Visual Studio IDE. While Visual Studio does let you run a Release build from within the IDE, it is highly recommended that you treat this feature as if it did not exist. You want to treat running the game in Release mode as if it was the packaged demo. When you double-click on the executable it should run without any debug dialogs, assertions, or exceptions.

This will be fully optimized and include a special #define symbol: NDEBUG that will affect the speed of standard functions, including: malloc(), calloc(), realloc(), free(), and assert().

IMPORTANT!
Be sure to be testing both Debug and Release builds periodically (do not leave this until the end of the quarter or weekly group demo crunch time!). When we have weekly group check-ups, we would like to see Release build demos.

<< Previous

:: Index ::

Next >>