Shall I move on to .NET?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Shall I move on to .NET?

      I am currently using Visual Studio 6.0

      If I move on to .NET, what new concepts do I have to grasp? Can I contiune programming without any interruption?

      And what is this Managed C++ and that .NET framework I have been hearing about? I heard mentions of new libraries - do I have to use them, or still stick to the familiar ones given?

      Also, does VC++ .NET resolves the STL implementation problems? How about templates?

      Thanks in advance.
      Act in haste and repent at leisure.
      Code too soon and debug forever.
    • VC++.NET implements the C++ standard much better than VC6. As far as I know, it's fixed the template issue. So far, I haven't run into any snags using it.

      .NET framework is like the next step in Windows programming. It contains a set of classes for you to use to help you write your programs with. You can basically write in any .NET aware language, and it won't really matter because all .NET aware languages are compiled down to IL, then when you execute the IL, it gets compiled down to native code and runs the application from there. You as a programmer write managed code in any of the .NET aware languages (C#, VB.NET, Managed C++.NET, etc).

      Managed C++ is (in my opinion) Microsoft's ad hoc way of getting current C++ programmers using .NET without disrupting their worlds by making them learn a whole new language. It's C++ that is designed to be compiled down to IL and use managed extensions and more or less follow the rules of .NET.

      If you get VS.NET, you *don't* have to use .NET framework or the managed extensions. You can continue coding in regular C/C++ (which is also called unmanaged code) with little, if any, interruptions. The extra libraries you mention refer to the .NET libraries, so if you choose to use the .NET framework and it's classes, then you'll have to make sure the proper version of the .NET framework is installed on the computer you plan to run the program. If you do decide to program managed code with the .NET framework, I'd recommend using either VB.NET or C# rather than Managed C++. From what I've seen of it, MC++ isn't exactly the cleanest and most elegant looking code, but that's my personal opinion.

      If you plan on getting VS.NET, you may want to hold on a bit. I think Microsoft will be releasing the latest version, called Whidbey, sometime this year. It's supposed to bring improvements to the .NET framework, as well as bring support for generics, which act as a template counterpart in .NET, along with some other enhancements. More info about the new VS.NET can be found here.
    • RE: Shall I move on to .NET?

      This isn't really a direct answer to your question, but it looks like Mike and I will have a VC6-compatible version of the Gamecode sources ready for public consumption in the very near future. So if you choose to wait a little longer before moving to .NET (like I am), at least you won't be left out in the cold as far as Gamecode is concerned.

      - David

      The post was edited 1 time, last by mystic_fm ().

    • Thanks for the reply!

      More questions forthcoming! How is Managed C++ different from Unmanaged C++? I suppose it is not ANSI standard, right?

      I also disctinly remembered that .NET only runs on the XP platform. Is that true? If so, it means I must get an OS upgrade before I could use .NET

      Lastly, does the framework aids in development of games? How friendly it is? How about execution speed?

      Thanks in advance
      Act in haste and repent at leisure.
      Code too soon and debug forever.
    • Managed C++ (MC++) brings in extra extensions to make writing programs for .NET possible. Although there's some things that may *look* similar to ANSI C++, MC++ is still more like a beast of its own. Check out this page to see a list of the various extensions added to C++. Also, here's the main page for Managed C++ Extensions of MSDN, so you can read up on the exact differences.

      As far as I know, the .NET Framework can run on Windows 98/ME/2000/XP (and I think Server 2003 as well, but don't know for certain). However, Visual Studio .NET won't run on Windows 98/ME. Check the system requirements for exact details.

      As far as execution speed, I've read many discussions on this, and from what I gather, .NET ought to perform quite well for most games. The figure Microsoft quotes is that managed code should perform 95-98% the speed of unmanaged code. In my experiences, nothing was abhorrently slow about .NET, but I just use it to build tools. I'd assume that it should perform well enough for a game.

      As for your questions about the framework aiding in development and its friendliness, well, those are a little more subjective. The latest DirectX SDK has support for Managed DirectX (MDX), which basically allows you to use DirectX in .NET programs. From what I've heard, people say it's cleaner and easier to program with, but I have no experience with it to back their statements up. I've also seen some C# wrappers for OpenGL on another site. So the tools to write games are available, it's just more or less putting forth the effort to learn how to use them well.

      Though, with regards to friendliness, there are some things about .NET that I like, such as its RAD abilities. Setting up a functioning window is a real snap, and adding components such as menus and toolbars is really a piece of cake. It makes building various game tools like resource packers and level editors easy. I really can't see myself going back to Win32 API or MFC to make tools. In the end though, I just look at the various languages and APIs as tools and choose the tool that allows me to get the job done the simplest and the fastest, and for some things (game tools), C# and .NET is the thing for me, whereas for other things (the actual game itself), unmanaged C++ suits my needs.

      The post was edited 2 times, last by MRom ().

    • On the topic of execution speed ...

      From what I've heard, when working with plain jane unmanaged C++ code, the optimizer in VS.NET is supposedly an improvement over the one in VC6. I've heard people say that an average piece of C++ code from a VC6 program can experience something like a 5% to perhaps even a 10% speedup just by compiling it with VS.NET. Of course that's just what I've heard, not having been in a position to try it myself. Maybe MRom or someone else can speak to the accuracy or fallacy of that?

      - David
    • I honestly don't have any facts that compare the speed difference between a regular, unmanaged C++ program compiled with VC6 and the same program compiled with the VS.NET C++ compiler. I've read in various forums that compiling a C++ program takes longer under VS.NET than it did with VC6. I haven't experienced any noticeable slowdowns myself though. Although, I'm guessing that the C++ compiler that comes with VS.NET has better optimizer than the one in VC6, so if that's true, it's bound to makes some faster code.

      Maybe Mr. Mike or someone else who has more experience using both products might be able to provide a better answer.
    • Managed Quake II

      If you are interested in comparisons of Managed and Unmanaged C++ programs then take a look at:

      vertigosoftware.com/Quake2.htm

      Vertigo have taken the GPL released Quake II code and ported it to both standard and managed MS C++ (and made them available for download). You need the pukka PAK files but it runs fine.

      They have even written a radar to show how easily it can be extended.

      Alasdair Russell (Dhericean)
      Gamma Testing - Where testing is extended to the full user community (AKA Shipping the Program)
    • I work in .net, so will throw my 5 cents in.

      I have no bias against C++ or C#.

      Okay - the three languages:
      C++ MANAGED
      C#
      VB .net

      Are the same language. You are essentially generating the same code when you program in these.

      When you call between .NET dlls, all calls between .NET components "appear" (and are assisted through the auto-completion support) to be in the language you're using. In essence, you've got 3 different views on the same language.

      Managed C++ has little to do with C++ other than its syntax, and that it can call into real C++.

      For example: A C++ Managed class can implement a VBasic interface, and a C# class can inherit from that C++ Managed class! (Note - this does not mean I am endorsing the practice of using inheritance in a software project).

      Visual basic is the stepchild, it's just a long-winded way of programming C# now, supported as legacy for VB programmers. But if someone wants to write modules in VB, you can still hook to them easily.

      C# is what you want to use to program DOTNET applications, EVEN if coming from a C++ background. It is familiar enough, and the Managed C++, while capable of doing the same things, is kind of long-winded and messy.

      Programming powerful robust networky interfacey applications in C# is something you can do so quickly and easily it's scary. VB.net and C++ Managed let you do the same things; but they are more long-winded about it. Between C# and C++ managed, C# is basically C++ managed with a lot of obnoxious symbols and keywords removed.

      With any .NET project you have access to the phenomenal libraries, which includes great GUI app and SQL support. This is nothing like MfC (a good thing).


      Use MANAGED C++ only for interfacing between C# programs and C++ programs or low level calls to things. It might be advisable to use it to interface with non-Dotnet/COM dlls as well. MANAGED C++ allows you to marshal types between the two language types in the same code.

      A managed C++ "Class Library" can contain the interfacing code between the C#/VB and the C++ it contains. Take the call in C++ Managed, and call through into C++ after converting the input data.

      The post was edited 1 time, last by mlamari ().

    • There's a lot of interesting talk at Ion Storm right now about using C# for game development tools like world editors or automatic testing harnesses.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • Looking back to the original question, it sounds like you're more concerned about what the new devstudio will mean to you as a C++ programmer, and whether you should use .net for actual game programming.

      The dev studio presents you with the option of writing pure C++ programs like you always did - but as already mentioned, template support has been cleaned up. Compared with VC 6? As a hardcore template abuser, I can tell you that the later Devstudio will compile template heavy code much faster - indeed, the threshole in the old tools for template heavy code was quite low - it would run out of RAM.

      As for using .net framework for game development? (Note, this means using C# and managed features, not just using the IDE for C++). This may sound like a rash statement; but, for any sort of remotely action game: NO. Writing the program in .net and optimizing the slow bits? NO, the murderous speed hits you'd get from otherwise mundane operations would make the most basic logic become the speed problem. Also, while .net makes it as easy as possible, integrating between the C# and the C++ itself has a speed cost at point of integration, and having to move this "break" point around would eat up a lot of development time.

      Another unfortunate consideration if doing a "budget" or "shareware" type title - the .NET framework came just too late to be included with Windows XP - successful titles in this market must work on Windows installations that even PREdate XP. Such users don't want the 25 meg download on their modems in a market of 2 meg downloads. This is frustrating especially considering .NET's possible suitability for the rapid development of simpler games.


      That said, it would be EXCELLENT for tools and the like. I think that the advantages of .NET development could get rid of the problem of tasking someone to write a tool over a 3 month period and ending up with nothing. . . . less experienced programmers can develop more solid tools over a shorter period of time, without becoming tripped up and bogged down in details.

      By the way - another advantage that .net development environment has over environments that APPEAR to give you as much form-editing ability, is that exotic custom controls are easily integrated into the dialog editor, and things like activeX controls/dlls can be just drag-dropped onto the form. This can be something like a 3D view window, or a movie/AVI display.

      The post was edited 1 time, last by mlamari ().