c# is slow. ok, its not cobol slow granted. But, for games, its slow enough not to bother with it, from the standpoint of someone can use c/c++.
yes, I admit, transition to new languageses has always come about in time, however, and this is quite a big however (open to debate), the difference between asm and c was huge in terms of speed to develop (more importantly debug). As game projects became larger asm was a huge bottleneck in the development timeline, and it was also quite hard to do team based development due to the nature of it. C compilers were getting good, and more people used it for various things. Nowadays, you rarely see assembler.
This time around, c# does not really offer anything significant over c++ (for games). ok its easy to use, but c++ isnt exactly mind bendingly difficult. c++ is easy to use, easy to manage, has very good debuggers (esp. windows based), the compilers produce extremely good machine code, can be used across all major formats, even handhelds. That is my point on this. c# is not currently cross platform, does not offer any huge advantage for games development, and is not as fast.
You do get (game) tools developed in c#, because you can get pretty decent gui's in a short space of time, and people are keen to have a go with it, I have used it myself and am impressed by it. I would not use it for game code though.
Commercial games need optimization and are still left wanting more speed (you always need more speed), so to use c# at this point is a no brainer, you dont, not for big commercial projects.
I still stand by my statement, that i dont think c# will ever be used to do big commercial games. Im sure someone will say "hey, I bought a puzzle game and that was writen in c#, well ok, im talking real games with 3D and physics etc.
The point of development times being reduced hmmm. I can't really see how using c# can have a major impact, if any. games, as a rule dont use win api gui's, apart from PC games that may use a teaser box on startup to give resolution options and the like. Nothing else c# provides could be used [over anything provided in c/c++]. Games companies rarely start from scratch with a guy tapping in void winmain() and starting from there. Getting the basic framework, and rendering 3d models with lights and whatnot is done very, very fast, to the point that its probably already there when you move to the next project, either from using the old code base, stripped down, or to build on, or there is a new project started by another team member ready for everybody to move to. Even then, it would take less than a week to get that done. Most other things are custom developed. Memory managers, containers, math routines, all developed either in house, or by a third party api/lib/src, or you use some of the stl.
That is why I ignored the "time to develop" issue.
[Edited by - Dot5 on December 5, 2005 5:17:15 AM]
Professional Games Made In C#?
I think a good solution to using C# in the game development world is quite simple. If anyone here has seen the scripting examples in the MDX SDK. Its pretty cool seeing as you can use it as a scripting language for games and perhaps have the engine itself in C++. There by utilizing C# and C++ as a whole, if the game code is easier to change around and you have a nice engine, why not?
You can argue that it will be slow but I really find that irrelevant statement after all, if your engine is coded well enough all the "slow" functions can be taken care of inside of it. Thus making your game fast, easy to maintain, update, and secure. That is where I find C# being used in games there, and for tool development.
Also, on another note as computers have been getting older, they have also been getting faster. Therefore eventually speed will be irrelevant, especially in a few years when quantum computers come out. They probably won't be in your home any time soon but they will be around.
EDIT:
Plus, I believe reversions of the .NET framework as it evolves, it will correct some of the issues. Thus making C#, and all .NET languages get better over time.
[Edited by - GDKnight on December 5, 2005 6:29:17 AM]
You can argue that it will be slow but I really find that irrelevant statement after all, if your engine is coded well enough all the "slow" functions can be taken care of inside of it. Thus making your game fast, easy to maintain, update, and secure. That is where I find C# being used in games there, and for tool development.
Also, on another note as computers have been getting older, they have also been getting faster. Therefore eventually speed will be irrelevant, especially in a few years when quantum computers come out. They probably won't be in your home any time soon but they will be around.
EDIT:
Plus, I believe reversions of the .NET framework as it evolves, it will correct some of the issues. Thus making C#, and all .NET languages get better over time.
[Edited by - GDKnight on December 5, 2005 6:29:17 AM]
I feel sorry for the guy who asked this question. 4 pages of C# vs C++ bitching and no answer to his question.
Professional Games made in C#?
If by professional you mean boxed, AAA, 5 Star games like Doom 3, Unreal, Half Life 2 etc, then the answer is none.
If you are already comfortable programing in VC++ 6, then stick with C++. You will get greater performance, but it will take you longer to generate your code.
But if you're just getting started with game development, go with C#. It will take a while for you to hit any real limitations... and by the time you do, C# may have a greater market penetration.
Finally, there are way more books on C++ available... the current crop of C# books are a bad investment. Half of them were written for .NET 1.1 and the sample code will not compile under 2.0 without substantial rewrites. Also, the MDX framework is still being finalised and tends to change with each release of the directX SDK... so in short, C# books are probably not the way to go just yet.
Professional Games made in C#?
If by professional you mean boxed, AAA, 5 Star games like Doom 3, Unreal, Half Life 2 etc, then the answer is none.
If you are already comfortable programing in VC++ 6, then stick with C++. You will get greater performance, but it will take you longer to generate your code.
But if you're just getting started with game development, go with C#. It will take a while for you to hit any real limitations... and by the time you do, C# may have a greater market penetration.
Finally, there are way more books on C++ available... the current crop of C# books are a bad investment. Half of them were written for .NET 1.1 and the sample code will not compile under 2.0 without substantial rewrites. Also, the MDX framework is still being finalised and tends to change with each release of the directX SDK... so in short, C# books are probably not the way to go just yet.
there are a lot of irrelevancies out there.
For the foreseable future all serious games will be developed in c/c++. Nobody i know is even considering its use for game code.
A good programming team can generate easy to maintain code etc in c++. Crap programmers who dont, will not suddenly create easy maintenance etc code just because they are using a different language.
This whole shebang is a moot point anyway, because professional development teams use c/c++ (maybe asm as well) for all the game code.
Write your games in c#, its not a crime is it, if you want to use it then thats perfectly fine. Its not really worth arguing over.
The original post regarded c# being used for professional games. Answer, no. "or is c# too slow to be used.], yes.
Books, well there are thousands of books for c++ with dx and networking, so a lot of new books will be c# based because there are not as many out there.
For the foreseable future all serious games will be developed in c/c++. Nobody i know is even considering its use for game code.
A good programming team can generate easy to maintain code etc in c++. Crap programmers who dont, will not suddenly create easy maintenance etc code just because they are using a different language.
This whole shebang is a moot point anyway, because professional development teams use c/c++ (maybe asm as well) for all the game code.
Write your games in c#, its not a crime is it, if you want to use it then thats perfectly fine. Its not really worth arguing over.
The original post regarded c# being used for professional games. Answer, no. "or is c# too slow to be used.], yes.
Books, well there are thousands of books for c++ with dx and networking, so a lot of new books will be c# based because there are not as many out there.
Quote:Original post by Dot5
... someone comes over and says, "you want to look at using c#, its much cleaner and easy to use".
Wow. Amazing how many times this response appears from people who really are not being asked to "look at using C#", not being asked to switch, etc.
Amazing the number of people who write all about how bad C# is, when that isn't even relevant to the posters question.
Amazing that people get so darned fired up about absolutely nothing.
C#/Java are modern version of Basic. If you understand that then you'll have no problems figuring out where C#/Java fits in.
Quote:Original post by snk_kid
[headshake] i'm not going to argue over C++ VS C# since i couldn't careless but that is a ridiculously dumb example, reason being that the win32 API has very little to do with C++ besides it's a C library and was never designed with C++ in mind, it's not the only GUI library available to C++.
Also that example is pretty much irrelevant with C++/CLI since the code becomes virtually the same (semantically that is):
Quote:Original post by HopeDagger
I understand you. ;) C# is inherently clean, but your opponent makes a good point of stating how with some higher-level wrapping, C++ can be just as clean, or pretty close. But it's not too fair to compare .NET Winforms with the Win32 API. At least compare C++.NET's equivalent:
*** Source Snippet Removed ***
Not beautiful, but cleaner than Win32. ;)
Ok I agree, the comparision wasn't fair. The point I was trying to make was that with C++ you often have to write more low level stuff code. I base that arguemtent on my own experiences with C++ though, and when I used C++ for games, I was too elitistic to use wrappers, I wanted to write all code myslef [smile], so if one wants, one can probably avoid most low level code.
And even if it's marginally, I still think that the C# version looks cleaner than C++/CLI counterpart. That's also pretty subjective though...
And now, Ladies and Gentlemen. I give you... Liiiiine-to-Liiiiine Arguiiiiiiiing. YAAAAY!
Quote:Original post by Dot5
[...] the apparent "ease of use" becomes irrelivant if it cannot do the job you want it to do.
What game programming related functionality were you unable to implement in C# that you could have done i C++?
Quote:
You should stop focussing on how clean it is, and look at how good it is.
[somewhat subjective]
All clean code isn't good code, but all good code is clean.
[/somewhat subjective]
Quote:
For the foreseable future all serious games will be developed in c/c++. Nobody i know is even considering its use for game code.
Well, I use it for game code, and I, as opposed to you, think that more and more games will be coded in C# in a foreseable future. The reason to this is the arguments in my previous posts.
Quote:
The original post regarded c# being used for professional games. Answer, no. "or is c# too slow to be used.], yes.
All this "C# is too slow" arguments, is that your own conclusion after spending some time with C# or is it quoted from other anti-C# persons? I'm just wondering.
what can I not get c# to do that I can do in c/c++? Well programatically, not much, but I was refering to the speed of the built code.
"All clean code isn't good code, but all good code is clean."
ermmm,
as for the slow argument, yes, I have compared it to c++. Now, you can do speed comparisons, and I have had people give me source and exe's showing that, like for like they are roughly the same. But the source is doing trivial things, even though they eat up time. large loops of simple calculation or assignments etc.
Now, if you code up something like a simple physics lib or lets see.. an a* pathfinder or geometry builder etc etc. Now, shift that over to c# and put a load on it. What I found was that c# would perform ok with a very light load. But, it becomes seemingly exponentially slower as you start to give it a lot to do. The c# tests brought the pc to its knees, with framerates < 1fps, while the c++ version was still running > 80. Now, this was using an extremely simple renderer, with no optimization on either end other than the algoritms themselves being optimized.
I am not anti c#, but if someone asks me if c# is used in professional game develpment, then im sorry but no, it most certainly isnt.
"All clean code isn't good code, but all good code is clean."
ermmm,
as for the slow argument, yes, I have compared it to c++. Now, you can do speed comparisons, and I have had people give me source and exe's showing that, like for like they are roughly the same. But the source is doing trivial things, even though they eat up time. large loops of simple calculation or assignments etc.
Now, if you code up something like a simple physics lib or lets see.. an a* pathfinder or geometry builder etc etc. Now, shift that over to c# and put a load on it. What I found was that c# would perform ok with a very light load. But, it becomes seemingly exponentially slower as you start to give it a lot to do. The c# tests brought the pc to its knees, with framerates < 1fps, while the c++ version was still running > 80. Now, this was using an extremely simple renderer, with no optimization on either end other than the algoritms themselves being optimized.
I am not anti c#, but if someone asks me if c# is used in professional game develpment, then im sorry but no, it most certainly isnt.
I've not used C# very much, but it does seem to be a little touchy when it comes to resource deprivation. For example, there's an oft-linked blog about how C# is much better off with a slightly non-standard game loop.
I wouldn't be suprised if something like that pathfinder or physics lib just didn't need a little tweaked to similarly operate better in the presence of a garbage collector.
I wouldn't be suprised if something like that pathfinder or physics lib just didn't need a little tweaked to similarly operate better in the presence of a garbage collector.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
