Ask a Dev. Why deosn't he Program in C#

Also i used Lua As a examply for the fact, that it has been around for 15 years Only recently has it been used More often.

I can recall saying c# is bad. I said it is used mainly for makeing programs.

C++ is also used for programs, but in the game industry its the bigger hand, I belive i read this some where, i am not sure.

It said something like

"c# has a solid programm that moves forward, while c++ is able to bend and is more flexible in it's code and optoins"

I am not 100% where when or if i even read that. i May of got mixed up. Don't rant me if its wronge.

Before i learn c++, i will learn C#, after i know c# and c++, i will learn lua. I see a futer in all of those, in the industry.

And what i ment in that first post is, Rpgs racing and most other titles are running good, I have yet to see a good fps or TPS,

Qout from wikipedia

Criticism

Performance C# programs, like all programs written for the .NET and other virtual machine environments such as Java, tend to require more system resources than functionally similar applications that access machine resources more directlyNow that deosn't look good to run a game engine.


Now, i am sure C# will become popular if Mircorsoft Wants it to, It's alot easyer to learn than c++. Time will tell

---

Hmmm.

leidegre:

I'd like to see a very thorough comparison between C++/C# not only regarding performance, but also looking at some language feats.

And what would be the use?  You'll always have bias and skewed results.  There are too many variables, and it's impossible to be rigorous enough to cover every aspect.  No matter what is published on the Internet, you'll still have people claiming C# is too slow for games, you'll still have people that think C++ is a dying/dead language.

Look at VS2008 support in XNA Game Studio.  There are FAQs and lots of threads about it here, but there are still new threads created several times a week asking the same questions.

Yeah, Pointless agrueing. Time will tell. Every one on this most likey sighned up to learn c#, there is your anser right here

---

Hmmm.

Madodaz:

Ask a Dev. Why deosn't he Program in C#

I am already answered this question but I can do it again.

Our main Problem with C# is the missing support for any other platform then the PC. Xbox 360 doesn’t count for us as we can’t ship boxed SKUs so far. Therefore we simply have no other choice than using C++.

For sure from a game developers point of view the runtime could need some improvements. But we talk about details and not the managed environment in general.

Great,

Basicly only Xbox360 and Pc support Full  C# coded based games.

---

Hmmm.

That isn't true. I've made games in C# using the Tao OpenGL library. It was quite easy. What you should be saying is that the XNA framework only supports PC and Xbox 360.

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

XNA framework only supports PC and Xbox 360- That was obvios,

So will My ps2 support A game based 100% on C#

---

Hmmm.

Madodaz:

XNA framework only supports PC and Xbox 360- That was obvios,

That assertion may have been obvious, but the correction was still necessary. C# is a language like any other. It is up to a platform owner or its users to develop a compiler and run-time CLR for the platform. OS X and Linux, for example, have the Mono platform (which I believe is open source) for a compiler and CLR. So it is worth mentioning that C# does not instantly mean XNA framework.

So will My ps2 support A game based 100% on C#

I don't know. Depends on if somebody has made a compiler and runtime for the PS2. I'm going to guess no.

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

Nick Gravelyn:

When you make a blanket statement like "C# is sloooow in a game engine" I think it's perfectly valid to point out that that isn't always correct. Some games (like racing games) probably don't need as much CPU power as others and would be perfectly fine using C#. C++ is slightly faster, yes, but C# is by no means vastly slower.

  IIRC, Quake II took a 20% speed hit going from unmanaged to managed C++. I'd assume that the difference going to C# would be slightly more, because the C# compiler isn't as smart as the C++ compiler. The version of Quake II wasn't pure C++, though. The ID team did some cool stuff in assembly so the difference between the consumer app and the pure C++ version was roughly the difference between the pure C++ version and the managed code version.

  Now for the caveats. All this testing was done using the software rasterizer. The differences were a LOT less noticable using the OpenGL engine. Also, the hardware's gotten a lot more powerful. Quake II ran quite happily on a 300 MHz PIII. My 5 year old computer clocks in at 2.6 GHz, and it wasn't top of the line, back then. Also, most computers these days have 2-4 cores. Efficient multithreaded C# should clean the floor with single threaded C++ code, all other things being equal.

So, C++ is faster than C#. C++ with good assembly code in the right places is faster than C++. Good threading and decent algorithms are probably a better win than going from C# to C++, so unless you're doing a game which really stresses your machine, I wouldn't worry about it that much.

 

mpswaim:

  IIRC, Quake II took a 20% speed hit going from unmanaged to managed C++.

How was it ported? When was this done? How was the '20%' figure measured? Managed code has a lot of things that need to be taken advantage of and avoided that C++ doesn't. The methods of porting make a huge difference. Simply saying it was ported doesn't accurately describe whether they tried to do the quickest port or if they tried to actually re-write parts using a managed-code train of thought.

I'd assume that the difference going to C# would be slightly more, because the C# compiler isn't as smart as the C++ compiler.

How so?

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

The Quake.net port that everyone remembers is this one http://www.vertigosoftware.com/Quake2.htm. Nick I think you were still in diapers back in 2003 ;-) You can read the white paper.

"Quake II .NET, a port of the
C-language based engine to Visual C++ with a .NET managed heads-up display. We
did this to illustrate a point: one can easily port a large amount of C code to C++,
and then run the whole application as a managed .NET application using the
Microsoft Common Language Runtime (CLR) without noticeable performance delays. "

Though the engine compiles in C++ .net 2003 its not a port to C#. Its compiled with /CLR but its still full of 'new' in the C++ sense not the .Net sense. They exposed enough of the engine to add some fully managed extensions.

"Running Quake II.NET in the timedemo test indicates the managed
version performs about 85% as fast as the native version. The performance of the
managed version was acceptable and testers did not notice a difference between the
two versions."

This was back in 2003 and since it was a failry naive direct port I doubt any optimisation was done.

Bottom line I don't think it was a good representation back then, and even less so now.

 

---

---

The ZBuffer - News and information for XNA and Managed DirectX

Someone did do a c# port of Quake 1 http://forums.xna.com/46180/ShowThread.aspx#46180 - though no real details on how or performance.

---

---

The ZBuffer - News and information for XNA and Managed DirectX

The ZMan [MVP/Moderator]:

"Running Quake II.NET in the timedemo test indicates the managed
version performs about 85% as fast as the native version. The performance of the
managed version was acceptable and testers did not notice a difference between the
two versions."

See that quote wasn't accurately represented above. The fact that the performance of the port, even in 2003, was not noticed by the testers means that the performance hit was negligable. If it runs 15% slower and nobody cares, does it really matter that it runs slower?

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

Testers != Game players with an obsession for frame rate || Game developers who think that 200fps makes games more fun

 

---

---

The ZBuffer - News and information for XNA and Managed DirectX

Nick Gravelyn:

If it runs 15% slower and nobody cares, does it really matter that it runs slower?

It wouldn't to me. If the C++ version ran at 80 fps, I'm not going to notice a difference when it runs at 68 fps (85%). I would be happy with that as a developer as well. If someone doesn't buy a Managed game because it has a lower (but not noticeable) frame rate than a native version, they're an idiot IMO. 8)

---

Jim Perry
Here's what I'm up to.

While not the hardcore of hardcore players, I'd assume they weren't testing it on people who have never played Quake before. Take into consideration that if there was never a released native version, there would be nothing to compare it to. So if the only version to come out runs fast enough to be enjoyable and there is no way for the players to know there is a faster version, they really have no reason to complain about it.

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

The speed difference seems to be less of a problem than the support for C#. Any game studio planning on writing games for PS3 or the Wii can simply toss the idea, because they won't work with C#. Also, unless you want to write a lot of wrappers, much of the 3rd party software developers use doesn't support C# (physics engines, game engines, etc....).

I absolutely love C#, but that doesn't mean that the industry will ever be willing to accept it. Open sourcing it would help, so that it could go multiplatform.

---

XNA QuickStart Engine | My site
"I'll be whatever I want to do!", Philip J. Fry

C# is cross-platform.

Trouble is convincing Sony or Nintendo that their platforms need a C# compiler/CLR when most companies tout gigantic libraries of C and C++ code. I believe that the heavy reliance on the old C/C++ is really why those will remain dominant for years to come. Not that the reliance is a bad thing (no need to reinvent the well and all that), but I'd say that between getting compilers and CLRs onto the consoles and the legacy C/C++ code bases, C# isn't going to become dominant for many, many years.

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

If I remember right, while C# compilers are made by companies other than Microsoft, microsoft has not open-sourced all of C# yet.

---

XNA QuickStart Engine | My site
"I'll be whatever I want to do!", Philip J. Fry

The whole language spec is available through the ECMA: http://www.ecma-international.org/publications/standards/Ecma-334.htm (there might be a newer version, but that's the first one that popped up). So I'm guessing there can't be much (if anything) Microsoft is keeping to themselves involving the language itself. Perhaps their CLR and compiler implementation, but the language is pretty much out there for anyone to use.

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

Nick Gravelyn:

C# is cross-platform.

I am one of the biggest Microsoft lovers out there and even I can't say that with a straight face ;-)

---

---

The ZBuffer - News and information for XNA and Managed DirectX

The ZMan [MVP/Moderator]:

Nick Gravelyn:

C# is cross-platform.

I am one of the biggest Microsoft lovers out there and even I can't say that with a straight face ;-)

It might not be as mature as Microsoft's CLR and compiler, but it works. I was able to run Mono compiled C# apps using Microsoft's CLR and vice versa. I made a basic OpenGL game using the Tao framework and C# in OS X.

---

---

Nick Gravelyn -- Microsoft XNA MVP
XNA Wiki | Zune Games

Nick Gravelyn:

mpswaim:

  IIRC, Quake II took a 20% speed hit going from unmanaged to managed C++.

How was it ported? When was this done? How was the '20%' figure measured? Managed code has a lot of things that need to be taken advantage of and avoided that C++ doesn't. The methods of porting make a huge difference. Simply saying it was ported doesn't accurately describe whether they tried to do the quickest port or if they tried to actually re-write parts using a managed-code train of thought.

Have some links-

http://groups.google.com/groups?q=quake+.net+assembly&hl=en&lr=&ie=UTF-8 &c2coff=1&selm=O1eXvxKSDHA.3796%40tk2msftngp13.phx.gbl&rnum=7

http://www.vertigosoftware.com/Quake2.htm

I'd assume that the difference going to C# would be slightly more, because the C# compiler isn't as smart as the C++ compiler.

How so?

The managed C++ compiler is the same compiler as the native C++ compiler, with a different target. It's pretty aggressive. The C# compiler's fairly dumb, and can't optimize "3+x+4" into "7+x". It relies on the JITter to do optimizations. While the JITter does a fairly good job, it works under constraints that the C++ compiler doesn't have, so it can't do as thorough a job.

mpswaim:

Have some links-

http://groups.google.com/groups?q=quake+.net+assembly&hl=en&lr=&ie=UTF-8 &c2coff=1&selm=O1eXvxKSDHA.3796%40tk2msftngp13.phx.gbl&rnum=7

http://www.vertigosoftware.com/Quake2.htm

I find their developer white paper rather disappointing as it doesn't really cover much of how the ported memory handling and things of that nature. I could read the source code, but I don't care enough to do that.

The managed C++ compiler is the same compiler as the native C++ compiler, with a different target. It's pretty aggressive. The C# compiler's fairly dumb, and can't optimize "3+x+4" into "7+x". It relies on the JITter to do optimizations. While the JITter does a fairly good job, it works under constraints that the C++ compiler doesn't have, so it can't do as thorough a job.

That's pretty strange. I didn't believe it until I tested it out and Reflectored it. In a naive sense I'm inclined to say that optimization of integer addition is not likely to be a bottle neck, but I could see how this would indicate that other areas of optimization are lacking.

Either way I still hold that if testers don't notice a difference and you don't release the native version for public comparison, that 15% hit is negligable. Even Vertigo Software said that the garbage collector and move to .NET in general (at least from my perspective while reading the white paper) was a good move. And as Andy mentioned above, this port was done years ago so who knows how much (i