Dev-Cpp vs Visual Studio 2008

by Dimi 25. May 2009 21:26

Hopefully this article won't get too polemic. I made some decisions about the future of some of my projects and most important of the art of software developing I want to continue.

I've worked for since the start of 1999 with the Dev-Cpp IDE which uses the MinGW compiler. The reason for this is that I didn't want to spend so much money on Visual Studio to get a C++ compiler. This was OK for me that time. Soon I noticed that it's not so easy to get everything compiled with the MinGW compiler. This compiler accepts only strict ANSII C++ so it was quite difficult to use some libraries available on the www. To get things done with MinGW compiler you had to download either a MinGW version of libraries or create them yourself. This was also OK for since most libs I was using were available for MinGW too. Problems began when I decided to develop on DirectX. I installed the DirectX SDK and got even on the simplest example application a bunch full of errors. So I put my ass down to get it work with MinGW. It was an nearly endless task and I won't go deeper into it. You can read the whole article here. When I got it finished I wanted to use some sound in my application. I decided to use the ogg vorbis format since I think it's still the greatest alternative to mp3. Again nor libs for MinGW and again some nights working on a DevPak. Community contacted me on my game site G-Productions wanting me to get the audiere audio library working with MinGW, others wanted the NVidia CG Toolkit to use with MinGW. At one point it was fun creating all this DevPaks. You can learn so much about compiler differences when working on this.

Again it was great fun the whole time, and it was OK for me having to spend some extra time on creating DevPaks first, to use them. Another great thing on the MinGW compiler was that code execution times are great compared to the code Visual C++ 6.0 created. You can read more about execution times in my previous article here. Now things changed since the .NET framework and I made some tests with the Microsoft Visual C++ Express Edition. The only thing I can say is WOW. If we compare the code execution times Microsoft made a big step forward. I had the chance to also test the Microsoft Visual C++ 9.0 pro edition and I'm thrilled. As a game programmer one of the most important things is (or should be) the code execution times. MS VC++ 9.0 rocks.

At some point I'm also glad not having to create a DevPak any more to develop something. Things get more difficult with the latest DirectX releases and I'm not sure if a conversion to a DevPak would be possible with the final release of DirectX 10. MS changed so many things in there.

What about the XNA framework? Maybe managed code is the future... Maybe the use of the XNA framework makes game development a very easy task but I will still use C++. Writing your own loaders, your own functions using the DX classes allows you more flexibility and I'm one of those old-school programmers who likes to know what his code does ;). No doubt, using the XNA framework saves you a lot of time and headache but you should decide for yourself what’s the best for your game. 

So what did you learn reading all this ideas and thoughts? I can highly recommend using the new Visual Studio. The performance on execution time is incredible. If you still use Dev-Cpp you most probably won't be able to use DirectX 10 but don't nail me on that, it's only speculation. If you come to the point where you want to use DirectX 10 you most probably won't have an alternative to MS VC++. Hey don't come with the "Dev-Cpp is free" paroles. You can get MS VC++ 9.0 for free (the Express Edition) ;)

Tags: , ,

game development

About compilers and code execution times

by Dimi 28. March 2008 01:44

I took some time to make some tests with compiler optimizations and while trying some settings and triggers I thought it would be interesting to profile the execution times of compiled code to see what the compilers really do.

Tools I used:

  • Paul Jackson's in-game-profiling library in C++
  • Dev-Cpp using MinGW v3.4.2
  • Visual C++ 2008 Express Edition

 

The following class was created:

   1: class ClassProfile   
   2: {   
   3: private:   
   4:     float x;   
   5:     float y;   
   6:     char szText[255];   
   7: public:   
   8:     ClassProfile();   
   9:     ~ClassProfile(void);  
  10:     
  11:     void    ExecDoLoop();  
  12:     void    ExecForLoop();  
  13: };

Listing 1

 

The following calls were made:

   1: ClassProfile m_Class;
   2: ClassProfile* m_pClass;
   3:  
   4: dev_ProfileBegin("ExecForLoop_obj_Outer" );
   5: m_Class.ExecForLoop();
   6: dev_ProfileEnd("ExecForLoop_obj_Outer");
   7:  
   8: m_pClass = new ClassProfile();   
   9: dev_ProfileBegin("ExecForLoop_pointer_Outer" );      
  10: m_pClass->ExecForLoop();  
  11: dev_ProfileEnd("ExecForLoop_pointer_Outer");
  12:  
  13: delete m_pClass;

Listing 2 

 

The testdrive

The function ExecForLoop consists of two cascaded for loops which perform some basic arithmetic operations. The three candidates are Dev-Cpp vs Visual C++ 6.0 vs Visual C++ 2008 Express Edition. In all the three IDE's an empty console application was created. A release version was compiled. The compiled version does not include compiler optimizations but was compiled using default settings.

 

Results in direct comparison:

Version Visual C++ 6.0 Visual C++ 2008 Dev-Cpp
  min max avg min max avg min max avg
ExecForLoop_obj_Outer (10 cycle) 0.1 0.1 0.1 15.1 15.1 15.1 0.1 0.1 0.1
ExecForLoop_obj_Inner (25000 cycles) 50.7 50.8 50.8 24.4 24.4 24.4 50.8 50.9 50.8
ExecForLoop_pointer_Outer (10 cycles) 0.2 0.2 0.2 30.6 30.6 30.6 0.1 0.1 0.1
ExecForLoop_pointer_Inner (25000 cycles) 49.3 49.4 49.3 26.6 26.6 26.6 48.7 48.7 48.7

 

What we see is that creating objects on the stack, the code execution time of VC++ 2008 is unbeatable with incredible 24.4 ms. VC++ 6.0 and Dev-Cpp runs equal with about 50.8 ms. But take also a look on the outer loop. Wow 15.1 ms for the VC++ 2008 but only 0.1 ms for VC++ 6.0 and Dev-Cpp either. Why that? To explain this you should have a basic understanding of the memories available on your machine and also compilers. The .NET framework has an incredible memory handler and so the compiler handles the code. While loosing some ms on the outer loop the inner loop with the time critical path takes half the time of the other compilers. Cool isn't it?

Now let's take also a look on our object that is created on the heap. What is the advantage of the heap? The heap provides you nearly endless memory (only limited by your hardware) but is slower than the memory on the stack but we see that all applications are faster on the heap than on the stack. So how can happen this? Quite easy. The allocation for the memory on the heap and the object creation is done only once with the line 8 in listing 2. The memory is already reserved for the function and so it can be executed as often as possible, it will always be fast since the functions calls the entry point in memory where everything is already stored. If we would create the object dynamic within a loop it would take much longer because the allocation handling and accessing is what makes the heap slower than the stack. The difference between VC++ 6.0 and Dev-Cpp is very marginal, again VC++ 9.0 is the winner.

 

Also interesting is the file size. 

Version Visual C++ 6.0 Visual C++ 2008 Dev-Cpp
File size 73,728 bytes 10,240 bytes 1,743,880 bytes

 

What do we learn from this table? Nothing we didn't already know but let's go more into detail. The smallest file was produced from the Visual C++ 2008 with about 10 Kbytes followed by Visual C++ 6.0 with 72 Kbytes and on third and last place with over 1.66 Mbytes comes the Dev-Cpp version.

Why are there such great differences? Let's start with the two extremes VC++ 2008 and Dev-Cpp. VC++ 2008 has such a small file size because it uses the .NET framework. That means that you need a framework installed which's download size varies between 22 - 195 Mbyte. The compiler simply stores the most necessary into the application, everything else (memory tables etc) is called from the framework. Dev-Cpp instead has a file size of 1.66 MByte because MinGW links from static libraries as much as possible. So a minimum on additional dll's and runtime environment is required but that increases file size of the application.

In other words you could run the Dev-Cpp console application on a new installed machine without having to install any other runtime or framework. You would have to install the Microsoft Visual C++ 2005 Redistributable Package to run the VC++ 6.0 application and you would even have to install the .NET framework to run the VC++ 2008.

I want to point out that all the three compiled release versions have been compiled without any compiler optimizations. I also want to point out that I used Visual C++ 2008 Express Edition with the .NET framework 3.5. As you know the Visual C++ 2008 Professional Edition provides an optimized compiler and could produce better code quality which would top the already great timings of above.

 

Didn't we forget something?

No I didn't (the first)!!! Borland fans will complain why I didn't refer to the Borland C++ Builder. Two reasons for that. First is that I didn't want to go through all the registration process on their website to register for a trial of their latest product Borland C++ Builder 2007 and I couldn't find my old CD with Borland C++ Builder 5. The second reason is that Borland doesn't provide a free version of this. This article is for those of you who don't want to buy a compiler for 900 $ when you are able to download one for free.

No I didn't (the second)!!! LCC IS NOT a C++ compiler. Although this is a great project (and I'm using this too) it's a C compiler and not a C++ compiler which makes it for me uninteresting. Don't get me wrong. I like lcc but I'm more the OOP guy.

 

Conclusion

I love Dev-Cpp and work as often as possible with this tool. Not only you learn to develop with C++ the ANSII "way" but it's free and uses, with MinGW, a very powerful compiler. It doesn't need any runtime or framework to run (when using standard functions). I learned to love Visual C++ 2008 and try to go more into deep with this tool. Microsoft offers a really cool IDE with, as we can see above, a really powerful compiler which produces good and fast code and all this for free. This is an important thing (especially when we thing of the endless discussions in bb's how bad Micro$oft really is... blablabla) when thinking to develop for private use.

Try it for yourself. All you need can be found below in the link section and you need the function timeGetTime() or a timer written in Assembler if you need a more accurate timing method ;)

 

Links

  • Microsoft Visual C++ 2008 Express Edition can be downloaded here
  • Dev-Cpp 4.9.9.2 with MinGW 3.4.2 can be downloaded here

Tags: , , , , ,

game development

blueEngine – a DirectX game engine

by Dimi 9. April 2005 12:58

About
The blueEngine is a high scalable and high performant game engine. It includes several modules such as support for sound, its own scripting engine and a network module. The blueEngine uses the DirectX 9.0 API and was fully developed with the MinGW compiler. Since the engine is still under development we won't follow the regular way and provide this engine as open-source but work on it as a base for some upcoming games in the pipe.
Features
Features Render-Interface:

  • BSP level rendering (PVS, frustum-culling)
  • octree rendering
  • shader model 2_0 and 3_0 support (native shaders and HLSL)
  • shadow volume rendering for real-time shadows
  • static models (LOD) supporting the formats MS X-File, 3DS, ASE
  • skinned mesh (skeletal animation) supporting the formats MS X-File, Cal3D
  • terrain rendering (LOD)

Features Audio-Interface:

  • 3D sound output
  • supporting WAVE, OGG and MP3 files

Features network-module:

  • client-server architecture

Features physics-engine:

  • ragdoll for Cal3D und X-File skinned mesh
  • full-scene collision for all scene objects like level and models

Features script-engine:

  • supporting XML, Lua and an own script file format
  • full integration of all components

planned features:

  • KI. Already designed a concept for path finding in bsp-trees

Additional information
The blueEngine uses the following 3rd party software or tools.

  • Dev-Cpp
  • Newton game dynamics
  • ogg vorbis sdk (MinGW version available here)
  • Direct90.DevPak (MinGW version available here)
  • Doxygen source code documentation

Q: What is the blueEngine?
A: The blueEngine is a high scalable, high perfromant game engine. It's written in C++ using the DirectX graphic api.
Q: Is the engine available for public use?
A: No, at current the blueEngine will only be used here at G-Productions and will be made available to partners of G-Productions. There are plans to publish a light version of the blueEngine for public use.
Q: It's a 3D engine right?
A: No. It's a game engine. The difference to a 3d engine is that the blueEngine consists of a render device, an audio device, a network module and a script engine. A 3d engine instead consists only of a render device for graphics.
Q: Why another game engine?
A: There are a couple of great graphic engines free available on the internet but nothing that meet our needs. So we developed our own.
Q: Is the blueEngine in any way related to the blueTec engine?
A: No not at all. The blueTec engine is a 2d graphic game engine with a basic audio module for people with less knowledge in programming to quickly getting results. The blueEngine is an up-to-date game engine competitive with many free available game engines out there.

Latest screenshots
These screenshots where made using specular highlight (shader model 2_0) and per pixel light

1-screen00 1-screen01 1-screen02 1-screen03 1-screen04 1-screen05 1-screen06

Tags: , , ,

game development

Powered by BlogEngine.NET 1.6.1.0
Theme adopted by Dimi with portions of Mads Kristensen and portions of Rtur.net

RecentPosts