For the past few months, I’ve been using Dev-C++ to program my SDL game. But after some consideration, I’ve decided to change my IDE from Dev-C++ to Microsoft Visual C++.  And let me tell you, if you are developing under a Windows environment, there really is no better.

In this article, I would like to share my experience to those who are trying to develop SDL games under Visual C++.

Why Switch to Microsoft Visual C++?

Dev-C++ has a shitload of bugs to iron out, and it doesn’t help that its development has been at a standstill since 2005. On the other hand, Microsoft Visual C++ provides an robust IDE with a respectable ammount of features (almost all of which are more robust than that of Dev-C++). And now that they’ve released it for free (Express Edition), there really is no reason why you would choose any other IDE on the Windows platform.

Setting Up the Environment

After downloading Microsoft Visual C++, you can cruise over to Lazy Foo’s tutorial, in which he will teach you how to get your project started. If you are using SDL_image, SDL_mixer or other such libraries, make sure to read this tutorial.

Remember to place all your .dll’s into the same directory as your binary. And make sure to set your working directory (Properties->Configuration Properties->Debugging->Working Directory) the same as your output directory (Configuration Properties->General). Not doing this will crash your app since it always requires all the SDL’s dynamic libraries to function properly.

Your app is generally in Debug mode, but if are compiling in Release Mode, you must set the working directory as the same as the output.

Furthermore, if you’re using a significant number of STL types (such as std::vector, std::list, etc), you could be experiencing performance problems because, for some odd reason, recent versions of MSVC leave in many runtime checks for things like iterator and element access in release mode by default. You may want to try setting the preprocessor definitions as so:

#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0

Lastly, if you are used to having the console, then just set SubSystem (Configurtion Properties->Linker->System->Subsystem) to Console.

Debugging

When I developed under Dev-C++, the way I debugged my app was by printing to console. What a godamn hassle it was and what a dumbass I was for not using it in the first place. With Microsoft Visual C++’s incredibly robust debugger, bugs that used to require hours of printing only took minutes!

To learn about all the awesome debugging features under Visual C++, read this article.

Memory Leak Detection

Be wary of  undeleted allocated blocks of memory and other things that might cause your app to slowly lose memory. If you are fearful that your app has memory leaks, there are several ways to check.

Visual C++ has a built in memory leak detection system, but for some reason, it only tracks memory C-esque leaks (such as malloc and free) but not on C++ memory allocation functions (new and delete). You would have to hook new and delete into its memory leak checker ; bottom line is, its not kew.

But there is an awesome memory detection that is just so easy to install – Visual Leak Detector (download link). It keeps track on exactly where the memory leak is being generated and also outputs your call stack so you can directly pinpoint where its happening.

Place all the files in the lib and include directory into Visual C++’s lib and include directories. Also, make sure to place the dynamic libraries (.dll) into the same directory in your app. Then, place this high above in your code:

#include <vld.h>

Profiler

Haven’t found a good free one, anyone have any suggestions?