All 3 have free C++ compilers. Which is the best for games? Has anyone used DigitalMars C++ or D?
On the GCC subject version 4 has an entirely new optimisation framework- atm it isn't as good as GCC 3.4, but it's a much cleaner and more hackable optimiser. It does some basic auto-vectorisation now and the optimiser is only going to get better.
GCC 3.x and 4.x are the most standard-compliant and trouble-free compilers I've used, which for me is what counts. They take their time to compile C++ though- particularly on windows. No idea why it's slower on windows...
"fortune" is a unix prog that dispenses randomly selected gems of wisdom from a database btw [:)]
id go with visual studio purely for the debugger. but thats me :)
gcc can be very anal, but it is the most standards compliant.
oh, and vs2005 is also free.. well, not quite, i dont think you can release software legally using the free compiler but its free to use until you get to that point. plus the MSDN docs are fantastic.
i assume you can still use pix with GCC generated directx code.. but its probrably something worth checking
MattD
[url="http://msdn.microsoft.com/vstudio/express/default.aspx"]vs2k5 is free in the Express edition for any purpose your heart desires including full commercial use.[/url]
however, it ships as a .NET2 compiler only. you need the platform SDK and some arcane magic to set it up for native apps. I can't find the link now but it's somewhere on the visual studio site.
In terms of every day usage and features and robustness I order the compilers so:
1st choice: MSVC - Hate it or not, this is the defacto standard, and by far and away the easiest to get going on a Win platofrm. I dont consider Linux a valid platform for development of common apps, because 90% of the market says so. Soz. Most of the applications I have made have been Win based as well (even tools for Linux systems and compilers).
2nd choice: gcc - Only used because of cross platform compatibility (for the few apps I need it for).
3rd choice: Ming - I have _had_ to use this for building some apps (ffmpg and so forth) and I simply dont like it. Far too much system modification, and little integration.
Ive also used various other compilers like ARM and MIPs and others. These are often quite an experience to get working on windows, although Metroworks ARM is pretty decent, pity about the IDE.
For making games on PC - Imho there is simply only one choice. MSVC. All other solutions will simply be full of difficulties in setup, and usage. The only time you might end up wanting to go gcc is if you need to do console, or handheld work. Even then though, you will end up with SNSystem tools (for Sony products), Metroworks (for Nintendo products) and MSVC for MS consoles.
quote:Originally posted by Grover
In terms of every day usage and features and robustness I order the compilers so:
1st choice: MSVC - Hate it or not, this is the defacto standard, and by far and away the easiest to get going on a Win platofrm. I dont consider Linux a valid platform for development of common apps, because 90% of the market says so. Soz. Most of the applications I have made have been Win based as well (even tools for Linux systems and compilers).
Hmm, VS2005 is the most annoying piece of cruddy bloatware I've used in years, it refuses to compile some perfectly legal c++, MS have screwed their crazy template dll export system, they've forgotten that people need to build the odd dll with the 'free' version (which installs that slimy windows 'genuine advantage' spyware): it's missing required libraries that don't come with the SDK and are impossible to download. I ended up copying them from a full install. The list goes on.
Then there's the insanity of the manifest stuff and msvcrt versioning stupidity... And the fact that they haven't bothered to implement the C99 standard by 2006!
MSVC2005 is still a pretty broken compiler. Much better than MSVC 6 admittedly, but it's still broken. Particulary with dlls and templates, which are two things I use all the time. It's a POS imho.
Just as a quick side note, anyone who's used MSVC for any length of time and found themselves swearing at the computer because Intellisense is just so **#^ing useless, should check out [url="http://www.wholetomato.com"]Visual Assist X[/url].
Some of my utterances within the first hour of use:
- "Holy crap! Intellisense actually works now!"
- "I clicked the "Go" button, and it when straight to the function definition!"
- "It's underlining misspelled functions and variables that haven't been declared yet!"
It's not perfect (it has some trouble dereferencing an iterator into a vector of Boost smart pointers, for example) but it is just so far superior to the MSVC offering that you'll easily forgive the minor shortcomings.
Fortunately, work is going to pay for it for me because there is absolutely no going back.
MSVC undoubtedly has the best debugger and most optimal compiler, I prefer the vc6 ide but a lot of people love the new ide.
It is basically what all game developers are using these days. They may use intel c++ but usually as a plugin to the visual studio ide which they still use. By the way, the majority of win32 binaries we put out ARE dlls.
Honestly Lorien, you cannot compare the amount of problems for setup on VS2005 against gcc or Ming. For the game developer you usually buy the optimised compiler, and studio. Having projects with both ARM compiler setups (for GBA/DS) and console projects and PC projects VS compiler is still by far the easiest to use, simply due to the IDE alone. What any nuances you have with templates are just as problematic on other platforms and other compilers if not more so. For example, try using advanced templates on a SGI machine like a Origin 4000 ... and these guys are supposedly the standards makers.
Btw I work with quite advanced template packages and dlls everyday, and I have found VS2005 to be the best effort yet. 2003 was pretty solid too, although the 2002/2003 workspace changes were annoying, but hey, nothing is perfect - name me a workspace in another application you could use on Win32 with similar features? There are plenty of instances with gcc and ming that show similar template problems - and for dll development, ming suks bigtime. And gcc - well.. yeah.. you can make dll's... no headaches though to get there though is there.. . Next you'll be telling me makefiles are awesome.. and Ant is brilliant.. :)
But we are talking about game development. And any serious game developer needs a good integrated IDE for development, debugging and verisoning. Most compiler makers have recognised the dominance and features of the VS toolset, so you will often find most compilers available to be usable within the VS environment in any case. For making games, you need something that supports DX, and MS Windows - like or hate it, this is the most common platform around, and simply the biggest gaming platform around.
If I were making cross platform tools I might recommend gcc, or if I were making IP that were to be released free that needed to be able to be compiled with free compilers I might choose gcc. But for games, it makes no sense to use anything else, its an industry standard. Ask any programmer in any game development studio. And please.. dont refer to Linux and OSX markets, sure there are games on these machines, but the Win32 platform outnumbers them 100 to 1.
What I think people should ask, is can I do similar things on a Win32 platform with any other toolset - ie compiling, debugging, editing, and versioning within a complete package with a fairly consistant interface? Thats the question - and honsetly there is simply no comparison. You have things like emacs, code::blocks, DevC++ and such, but they are so far away from a game development toolset its not funny.
I have spoken to a games programmer from a reputable games company making games for PS2 who does all his coding using GCC as compiler and Vi as editor. While I use MSVC now, at university I did all my coding the same way. To an extent I think I wrote better code back then simply because an IDE that does too much for you can promote lazy programming practices.
The question as far as I can tell is "How do I like to work and what toolset will support that?". Sometimes that choice is severely limited by the platform you might be targetting: if you're targetting Xbox then you are pretty well limited to the obvious. But you don't _need_ MSVC and DX. OpenGL is still the superior API, in my opinion, and there are a lot of games guys out there that use it...particularly if you're targetting Playstation.
My point is that whatever you're chosen toolset, you actually have to work with the thing and if you find yourself, instead, constantly fighting with it then you've probably made the wrong choice.
Im purely speaking from a work experience point of view. I too know emacs and gcc fans that stayed on that on PS2 dev - however if you have ever used SNSystems compiler, ee & vu debugger youd soon realise how poorly productive you are. And thats not based on peoples preferences, or otheriwse, its purely from a feature set, and capability standpoint. I remember at a certain games co, they simply didnt warrant spending the cash on such tools, and thus always languished behind other studios that did.
Lazy programming practices dont come from IDE's at all, in fact they originate from poor design practices. A half decent IDE will save you _hours_ over a non-integrated one for example - in debugging time alone. This again, isnt from simple adhoc commentry, this is from some 10 yrs in the business of building apps, games, sims etc.. I have used quite a many of the tools you speak about for professional work, from gcc, to msvc, to arm, to sgi, to console (PS2 snsystems and gcc), with varying IDE's, from metroworks, to VS, to nedit, to emacs, to vi, borland, devc++, and code blocks to name a few (even a couple of my own tcl based toolsets). The fact is its a job - your aim is to do the work efficiently, effectively and in the smallest possible timeslot you can with no bugs :) ... MSVC goes far further in achieving this, than any other setup on Win32.
Whether you 'like' a toolset is almost utterly ignored these days. You need to use the tools that dev studios buy. Game studios (or ones with some form of cash) buy decent toolsets. Unless you are a core engine programmer on PS3, these days, MSVC is simply what you will NEED to know, understand and use. Im not promoting MS products, and as lorien knows I personally abhore MS as a company. But I am simply talking facts about making games. I even personally still use Fedora Core 4 and various Linux based tools to build many apps, but not games. I cannot see that any game coder would put gcc in front of the MSVC tools (and attached SN Tools and compilers for PS2). If you are still using Vi and gcc on PS2 - you need to get 4K.. and buy some decent tools.
As for OpenGL still the superior API - thats sadly very, very, very, mistaken. OpenGL is in the throws of being reinvented, and may see the light of day with some improvements (hopefully) but it is currently so far behind DX in functionality and usability alone, its horrible for use with games on PC (even though many people will wave the GL flag enlessly). The main reason for this is extensions, and shaders. GL has no serious comparative shader language to match HLSL. Again, dont quote GLSlang and GLSL, because that then will just show how little you know about HLSL. Its a sad fact - and very sad, because the GL API used to the be the best around by far. Now with the horrors you need to go through to get a wide range of PC cards running shaders... its a waste of time. While you spend months writing fallbacks to cover your shaders, you could have written a single HLSL file - installed DX9.. and youre dun.
PSP and PS3 will use OpenGL, but not the true OpenGL. Its OpenGL ES (PSP has a hacked up API of its own really). PS3's Open GL ES shader system uses underlying Cg NVidia gear - which is sensible for a specific platform, but it aint pretty to use. Hopefully OpenGL can make a transition through to something back to its original greatness.. but as it stands at the moment, its a pretty sad mess.
Finally, if you _dont_ go an leanr to use MSVC, you will simply be doing yourself a disservice for two main reasons:
1. You will fall behind in use of the most commonly used game development tools - esp debugger, versioning integration and so on.
2. You will find it hard to work with other people/studios that predominantly use MSVC for game development.
What I find most bizarre though about gcc lovers, is that anyone can even remotely call using makefiles and/or ant to build large game projects as being a good choice against workspaces. If you thought MSVC had probs.. my god.. try a large scale project with make and ant...
Point certainly very well taken and understood. However, I interpreted the orignal post in the context of homebrew development, in which case, as I've already said, there are a few more things to consider.
As for OpenGL, I fully realise it is languishing...and no small part of that is probably due to SGI handing over all the IP to Microsoft for cash in order to save their sinking ship. In some ways it's difficult to compare OGL and DX because their design philosophies are quite different, and one should note that DX can make some obvious assumptions about the platform it is running on where OGL can't.
What I liked about OGL was that, for one it's API is elegant and clean. It's a C API and doesn't try to be anything else. DX doesn't know if it's C or C++ so we've got classes but every name has a prefix of some sort tacked on to it (which is what namespaces are for!) plus there's Microsoft's COM paradigm to contend with. The other thing is it is pretty easy to get something going quickly in OGL with only a few lines of code, which is important to me because I do a lot of prototyping and proof-of-concept work. In DX, I groan at the thought of yet again seting up all the vertex and index buffers just so I can test an idea. Performance at this stage is irrelevant. (Some of the DX extensions might help here but most of the time they aren't an option.) No doubt OGL vertex buffers involve the same pain, but you don't have to use them if you don't want to whereas you have no choice in DX.
Having said all that, I've not had a lot of experience using OpenGL...what little I do have was actually quite pleasant. I haven't used GLSL at all so I can't comment on it but I'm not sure what you're getting at with HLSL. You still have to write fallbacks if the GPU doesn't support the shader version you are using. An HLSL shader can't magically rewrite itself depending on the capabilities of the GPU. If you're talking about the DX Effect system, it might make writing fallbacks easier but it still doesn't do it for you.
Hrm. Even as a homebrew developer on Win32 - the points still hold. By not using many of the industry standard tools you are simply alienating yourself and as I mentioned, making things harder for yourself down the track. Again Im not talking about my own personal preferences, since that should not be accounted for when trying to determine the most useful toolset for developing games on Win32.
The simple fact is in OGL you cannot use advanced HW GPU techniques as easily - in HLSL I am referring to techniques. This method of writing mutliple platform compatible shaders is not available in OGL. Yes, DX WILL do many things for you to abstract the platform (especially in relation to shaders) - thats the whole reason OGL is so far behind. My guess is you probably havent done alot of shader work in GL or DX. I can write a single fallback in a technique in HLSL that will work on both ATI, NV and Matrox and others. Try doing that in OGL - you cannot. So what you say is untrue - HLSL is a high level language that is built to be able to be used on multiple types of GPU's - this is its utterly huge benefit. You try and support multiple GPUs in OGL - even if you use say ARB extensions (which are supposed to be a GPU standard) you'll find so many differences in how the cards implement the ARB standard its crazy. In fact, sadly even OpenGL itself isnt implemented properly on all platforms - for instance fog is implemented differently between ATi and NV, and in OGL with shaders you can easily become caught by this, and in DX its all nicely abstracted for you. On DX that problem is reduced massively. Again this is much more important when writing a PC game, where you want as wide exposure as possible with minimal effort (especially if you are working from a homebrew perspective).
Overall, I like the OpenGL API and I even use it in my own apps/tools/homebrew (see LuaEng for example) but again, its not correct to promote an API that is severly flawed, or ignore a toolset that is an industry standard. Personally I dont _want_ to agree with what I have pointed out - but these are _glaringly_ obvious facts not some rant of an old grumpy coder (although.. hehe they look like it). But I dont beleive in pushing information that doesnt hold true. With relation to development, I think personal favouritism should take a back seat - I prefer a balanced critique of the realities of these tools and system especially when you relate to game development and Win32. Things change dramatically if you are restricting your platform, or your OS, or your application type (and associated market). But this is games...
quote:Originally posted by Grover
Im purely speaking from a work experience point of view. I too know emacs and GCC fans that stayed on that on PS2 dev - however if you have ever used SNSystems compiler, ee & vu debugger youd soon realise how poorly productive you are. And thats not based on peoples preferences, or otheriwse, its purely from a feature set, and capability standpoint. I remember at a certain games co, they simply didnt warrant spending the cash on such tools, and thus always languished behind other studios that did.
Using GCC doesn't mean the whole emacs/vim deal, there are plenty of IDEs with all the features of MSVC (ok, except intellisense). Try Eclipse with the CDT and subeclipse and scons extras or KDevelop (Unix only) for example. I have no arguments about makefiles being nutty, and the gnu automake/autoconf is even more cryptic. Likewise I don't use GDB directly, but through a gui.
quote:
The fact is its a job - your aim is to do the work efficiently, effectively and in the smallest possible timeslot you can with no bugs :) ... MSVC goes far further in achieving this, than any other setup on Win32.
My main problems are with the compiler and linker, not so much the IDE. It is bloated though. Also by being so tailored to win32 MSVC gets in the way of cross platform software somewhat.
quote:
Whether you 'like' a toolset is almost utterly ignored these days. You need to use the tools that dev studios buy.
Depends what for I think. I don't make commercial games and have no intention of doing so. I have to teach MSVC at work though- even Managed "C++" this semester [:(]
For linux dev it's expected to be a GCC wizard, in the same way as for game dev it's expected to be an MSVC wizard. It's a toolset you find everywhere, so is a very handy thing to be experienced with.
I think for non-commercial games built using open engines and libraries MSVC isn't the automatic choice simply because open code gets compiled far more often with GCC than MSVC, so is far more tested with that toolset. Open libraries are sometimes badly crippled when you build them with MSVC due sometimes to broken parts of MSVC and sometimes due to use of GCC language extensions.
Anywhere that stability of generated code and cross-platform compatibility is desired over optimiser speed GCC is the way to go imho.
quote:Originally posted by lorien
quote:Originally posted by Grover
Im purely speaking from a work experience point of view. I too know emacs and GCC fans that stayed on that on PS2 dev - however if you have ever used SNSystems compiler, ee & vu debugger youd soon realise how poorly productive you are. And thats not based on peoples preferences, or otheriwse, its purely from a feature set, and capability standpoint. I remember at a certain games co, they simply didnt warrant spending the cash on such tools, and thus always languished behind other studios that did.
Using GCC doesn't mean the whole emacs/vim deal, there are plenty of IDEs with all the features of MSVC (ok, except intellisense). Try Eclipse with the CDT and subeclipse and scons extras or KDevelop (Unix only) for example. I have no arguments about makefiles being nutty, and the gnu automake/autoconf is even more cryptic. Likewise I don't use GDB directly, but through a gui.
Hrm - I think people might slap you for the Eclipse comment (at least most of the Java coders I know hehe) :) Again, for Win32, and games.. Id be very hesitant for that combo at all - maybe a Java game? Hrm.. even Netbeans is nice.. but it aint no VS.
What I was referring to was the compiler though. SNSystems compiler, linker and debugging toolset for PS2 vs the gcc based one that comes with the PS2 devkit, is like chalk and cheese - gcc being horribly cheesy. Again, you need to use the both to see what I mean, the difference in productivity is quite obvious. And a person whom uses gcc on PS2 is simply missing out - ie its not a good example in the pros for gcc. The SN compiler was originally gcc based even - but has been improved.. a touch ;)
quote:
quote:
The fact is its a job - your aim is to do the work efficiently, effectively and in the smallest possible timeslot you can with no bugs :) ... MSVC goes far further in achieving this, than any other setup on Win32.
My main problems are with the compiler and linker, not so much the IDE. It is bloated though. Also by being so tailored to win32 MSVC gets in the way of cross platform software somewhat.
For me its the whole working package. And for most people. Once you start splitting the compiler, linker, debuggers up - you just end up with heartache. From my exp, there have been many times where the three tools have been entirely seperate. This decreases your development capabilties bigtime. Coders simply dont have the time to learn different toolsets and nuances of each compiler and system to be developing with. Gcc, and its linker is a classic example here, where knowing options is core to getting the best from the compiler/linker (and sometimes just getting it to work - homebrew psp gcc for instance) :) I know.. its horrible to think that programmers should not have to worry about these things, but I beleive in this day and age, they shouldn't. Unless you are a compiler writer, or maybe a performance tuner, you should be able to just get and code asap - in 20 years time, Im sure we wont even want to know how C++ works :) (in reference to how few people even bother with gas and such these days).
Again, not something I prefer, but something I believe is simply logical - Would you spend time learning how to code in Forth? Would you spend time learning how to get the best out of an Origin 4000 (geez.. that was a waste)... and so on. By focussing your efforts to the optimum, you then have the best chance for jobs, for support, and for future development options.
quote:
quote:
Whether you 'like' a toolset is almost utterly ignored these days. You need to use the tools that dev studios buy.
Depends what for I think. I don't make commercial games and have no intention of doing so. I have to teach MSVC at work though- even Managed "C++" this semester [:(]
Yep. Agreed. Its very application specific. However, gaming is 90% Win32 these days. Again, this is a matter of fact and making best use of energy expended ;) Do you target a niche market (btw Im not suggesting not to - but make sure you do your homework on the market first).. or do you target a much bigger audience with better likelihood of success or exposure?
quote:
For linux dev it's expected to be a GCC wizard, in the same way as for game dev it's expected to be an MSVC wizard. It's a toolset you find everywhere, so is a very handy thing to be experienced with.
I think for non-commercial games built using open engines and libraries MSVC isn't the automatic choice simply because open code gets compiled far more often with GCC than MSVC, so is far more tested with that toolset. Open libraries are sometimes badly crippled when you build them with MSVC due sometimes to broken parts of MSVC and sometimes due to use of GCC language extensions.
Yep. For non-commercial open sourced libs are ideal, and very often ggc - if you are looking for gcc solutions :) There is also a fairly large amount of VS only based libs and such too. All depends really where you shop :)
Also, I hate to say it, but open sourced gaming isnt exactly burgeoning with numerous hot game titles :) Although... I do like that TA clone :) But Im sure there are plenty of good titles around, its just that like most things in this world, cash gets you resources.. and in making games.. thats pretty much a necessity. Ask any indie here :)
quote:
Anywhere that stability of generated code and cross-platform compatibility is desired over optimiser speed GCC is the way to go imho.
Hrm. Stability is debatable :) - there are plenty of issues in gcc too . Its not immune from problems creating quality code. It certainly has a good turnover of people trying to improve it - albeit introducing issues as well sometimes ;) It is definitely the only choice for cross-platform however, and that is important if you are looking to make a cross platform game. Espeically people interested in homebrew.
Actually I'll insert a fat disclaimer here:
For homebrew lorien is dead right - gcc is prolly the best choice by a mile for DS, GBA, PSP, PS2 etc .. if not the only choice. Getting VS to help building with those can be a pain (it is doable in 2005 though I should point out - with a pretty simple plugin).
Mind you gcc is a mammoth effort, many languages supported, many platforms, binary types, and so on - it really is amazing it compiles anything :) But it is impressive, no doubt about it. In that light alone gcc stands very tall in my book, but again I'll note Im talking Win32, and game development, and Id love to use gcc for game dev (actually i do in a couple of instances :) .. Code::Blocks + gcc for homebrew PSP) but its not a serious answer for PC Win32 DX development.
On the flipside to my argument is that if you extrapolate what Im saying about generic development systems and programmers not needing to be at the low level - Im not sure Id actually want that to be the case. But I do recognise that systems, OS's, libraries are all becoming increasingly complex, and that programmer roles are becoming more and more specialised. I'd very much personally HATE MS to end up with a strangehold on the tools we use to develop - but unless someone comes along with a serious competitor (with a good integrated debugger).. we are stuck.
Anyone got a comparable IDE to VS for game dev? Im keen to hear if there is something new around I havent heard of that can flush this argument of MS away...
quote:Originally posted by Grover
Hrm - I think people might slap you for the Eclipse comment (at least most of the Java coders I know hehe) :) Again, for Win32, and games.. Id be very hesitant for that combo at all - maybe a Java game? Hrm.. even Netbeans is nice.. but it aint no VS.
Eclipse 3.1 with the CDT is very cool indeed once it's set up properly. I know quite a few java coders for whom it's the only IDE worth using.
quote:
What I was referring to was the compiler though. SNSystems compiler, linker and debugging toolset for PS2 vs the gcc based one that comes with the PS2 devkit, is like chalk and cheese - gcc being horribly cheesy. Again, you need to use the both to see what I mean, the difference in productivity is quite obvious. And a person whom uses gcc on PS2 is simply missing out - ie its not a good example in the pros for gcc. The SN compiler was originally gcc based even - but has been improved.. a touch ;)
If it's based on gcc they are likely in breach of the GPL: I haven't seen the compiler sourcecode around anywhere... Correct me if wrong of course. I have nothing to do with ps2-dev.
quote:
For me its the whole working package. And for most people. Once you start splitting the compiler, linker, debuggers up - you just end up with heartache. From my exp, there have been many times where the three tools have been entirely seperate. This decreases your development capabilties bigtime. Coders simply dont have the time to learn different toolsets and nuances of each compiler and system to be developing with. Gcc, and its linker is a classic example here, where knowing options is core to getting the best from the compiler/linker (and sometimes just getting it to work - homebrew psp gcc for instance) :)
Umm MSVC is exactly the same. If anything it's options are more cryptic and make it even easier to brake binary compatibility...
quote:
Again, not something I prefer, but something I believe is simply logical - Would you spend time learning how to code in Forth? Would you spend time learning how to get the best out of an Origin 4000 (geez.. that was a waste)... and so on. By focussing your efforts to the optimum, you then have the best chance for jobs, for support, and for future development options.
I think the game dev crowd should try and get over making a broken compiler and linker their standard tool myself... I find I simply can't do things with MSVC that are no problem at all with GCC, and they are useful things (ever been bitten by MSVCs template/dllexport issues?). I argue that MSVC isn't the optimum at all and has never been.
quote:
Yep. Agreed. Its very application specific. However, gaming is 90% Win32 these days.
And game-dev is a tiny niche for programmers.
quote:
Also, I hate to say it, but open sourced gaming isnt exactly burgeoning with numerous hot game titles :)
Nor is commercial game dev :)
quote:
Hrm. Stability is debatable :) - there are plenty of issues in gcc too . Its not immune from problems creating quality code. It certainly has a good turnover of people trying to improve it - albeit introducing issues as well sometimes ;) It is definitely the only choice for cross-platform however, and that is important if you are looking to make a cross platform game. Espeically people interested in homebrew.
GCC isn't perfect by any means, it's just much better than MSVC... SOmetimes I wonder how many of the problems in windows are actually caused by MSVC bugs.
quote:Originally posted by Grover
The simple fact is in OGL you cannot use advanced HW GPU techniques as easily - in HLSL I am referring to techniques. This method of writing mutliple platform compatible shaders is not available in OGL. Yes, DX WILL do many things for you to abstract the platform (especially in relation to shaders) - thats the whole reason OGL is so far behind. My guess is you probably havent done alot of shader work in GL or DX. I can write a single fallback in a technique in HLSL that will work on both ATI, NV and Matrox and others. Try doing that in OGL - you cannot. So what you say is untrue - HLSL is a high level language that is built to be able to be used on multiple types of GPU's - this is its utterly huge benefit.
At the risk of sounding petulant, I've been working with HLSL now for around 12 months. HLSL is not able to be used on multiple GPU types simply because it is a high level language. HLSL code is still compiled to an object code that will only work on GPUs that support the instruction set, i.e. shader version, for which the code was compiled. So if you compile an HLSL shader targeting shader version 2.0, that shader will run on any GPU that implements the shader version 2.0 instruction set. I have had trouble lately because I've been using Shader 3.0 for everything, and up until very recently, ATI did not produce any GPUs that supported it; only NVidia.
So what you say is not strictly true - you can write shaders (as well as techniques but you don't have to use techniques if you don't want to) that will run on anything but the reason is not because you are using HLSL. You can go back to the pre-Cg days and write assembly code that will do that. It's because the GPUs support it.
And I've said before, I've not had any experience with OGL shaders or GLSL, so I'll just have to take your word for it, as far as that goes.
...and to sum up:
MSVC is "Better" than GCC because...
Mac is "Better" than PC because...
OGL/DX9, ATI/Nvidia, Ford/Holden, XXXX/VB, apples/oranges, chalk/cheese...
My experience is that if you're used to working with GCC, MSVC is a pain and Vice versa. However right or wrong it is, MSVC is the 800 pound gorilla in the gamedev industry and you should ignore using it at your commercial peril. Those in research or at lower levels of abstraction will probably be at the point where they can make an educated choice of one over the other based on their own needs but the rest of us peons work with what we're given to focus on the job, not the tools.
-d
Stay away from Borland is my advice. It's highly non standard C++ and in my own experience is far more trouble than it's worth.
Lots of people like MSVC. I prefer GCC (though I admit MS have a better optimiser atm).
Stay away from Cygwin if you're interested in GCC for games, use mingw32.
D is not compatible with C++, which could make using DirectX interesting.