Jump to content

  • Log In with Google      Sign In   
  • Create Account


Why C# XNA When Everyone Wants C/C++


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • This topic is locked This topic is locked
165 replies to this topic

#41 Promit   Moderators   -  Reputation: 6143

Like
0Likes
Like

Posted 04 March 2009 - 10:52 AM

Quote:
Original post by Fiddler
Mac and Linux aren't relevant? The makers of World of Goo would beg to disagree:
Quote:

Update 4: It’s only been 2 days since the release of the Linux version and it already accounts for 4.6% of the full downloads from our website. Our thanks to everyone who’s playing the game on Linux and spreading the word. Here are a couple of nifty stats:
[...]
More copies of the game were sold via our website on the day the Linux version released than any other day. This day beat the previous record by 40%. There is a market for Linux games after all :)
Of course their publisher still went under, so apparently making a fabulous game that is also available for Linux and Mac isn't quite sufficient to save your business on its own. Still, more power to them I suppose.

Sponsor:

#42 Josh Petrie   Moderators   -  Reputation: 2956

Like
0Likes
Like

Posted 04 March 2009 - 10:54 AM

Quote:

You guys are getting olllllddddd, two pages and it's all over.

By the way, you call that C# binding of Bullet & PhysX SDK?

Come on!

Contribute meaningfully, or please go elsewhere.

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#43 sybixsus   Members   -  Reputation: 210

Like
0Likes
Like

Posted 04 March 2009 - 11:02 AM

Quote:
Original post by Promit
Of course their publisher still went under, so apparently making a fabulous game that is also available for Linux and Mac isn't quite sufficient to save your business on its own.

If you mean Brighter Minds, Brighter Minds were only selling the Windows version, so if anything this proves the opposite.



#44 xylent   Members   -  Reputation: 100

Like
0Likes
Like

Posted 04 March 2009 - 11:10 AM

Quote:
Original post by Promit
Quote:
Original post by Bru
but in the end c++ games are faster than c# games and mostly we only care for the result.
And this is precisely the kind of blatant falsehood that is downright dangerous in these forums, and which I and several other moderators (along with any number of long time members) have been working to shut down.


I believe that we can say it is easier to write slow (resource inefficient, in general) programs to write in languages like c# not solely because of the language itself but also because many c# programmers tend to think that the .NET (or whatever underlying platform) will handle too much for them whereas many c++ programmers know that they have the control, hence are responsible for certain things.

Quote:
Original post by swiftcoder
Don't forget that there was a time when C++ was considered far too high-level and slow to be useful for game development (vs C) - and there was an even earlier time when the same was said about C (vs assembly language).


The bounds between c, c++ and assembly languages are conceptually different than that of languages that belong to the family of c# and java. Today, with the help of optimizing compilers, it is possible to create the fastest code with languages like c, c++ when used properly. It is VERY unlikely that you will write the same program in a more efficient way in assembly than in c/c++ unless:
- you are extremely skilled in assembly programming
- you know all the details of the underlying hardware architecture

Even so, considering the complexity of writing a reasonably large application in assembly, chances are very high that it will run faster when written in c++. It is fairly obvious that the bounds between c, c++ and assembly programming have been almost vanished. This is not the case with interpreted languages and will never be. Because native code will always run faster than interpreted code regardless of how much faster our cpu or memory gets, unless you believe that there will be such times where the processing power will just be enough for all kinds of applications written in any language, which I strongly suspect.

Having said all these, c# may be a good starter (not saying it's not good beyond starter level), since you have many libraries ready for use with c# + XNA combo and you can focus on your game instead of the game engine and external libraries.

#45 Drilian   Members   -  Reputation: 1025

Like
0Likes
Like

Posted 04 March 2009 - 11:17 AM

Quote:
Original post by xylent
I believe that we can say it is easier to write slow (resource inefficient, in general) programs to write in languages like c# not solely because the language itself but also because many c# programmers tend to think that the .NET (or whatever underlying platform) will handle too much for them whereas many c++ programmers know that they have the control, hence are responsible for certain things.


And I bet you have a BUNCH of information to back that statement up, right? Right? No? Oh.

This is exactly the kind of bullshit that Promit was talking about. You don't know, but rather than keep your uninformed and incorrect opinion to yourself, you decide to share it with the world like it's gospel.

Look, if you're a bad programmer (proverbial you, not you specifically), your code is going to be bad in whichever language you use. But if you're using an efficient high-level algorithm, you're going to get good performance out of either language.

The correct way to phrase your statement is "inexperienced/bad coders won't always write efficient code." Wow. What a revelation.


Quote:
Original post by xylent
This is not the case with interpreted languages and will never be. Because native code will always run faster than interpreted code regardless of how much faster our cpu or memory gets, unless you believe that there will be such times where the processing power will just be enough for all kinds of applications written in any language, which I strongly suspect.


We're talking about interpreted languages? Shit, I thought we were talking about C#, which is actually compiled to native code before it runs (You know, that whole "Just in time compiler" thing).

I (somewhat) apologize for my tone, but I get sick of people continually ragging on something that they obviously know nothing about. The reason that the "C# performance is bad" myth sticks around is because people like you keep spouting your uninformed bullshit like it's truth.

Just stop.

#46 xylent   Members   -  Reputation: 100

Like
0Likes
Like

Posted 04 March 2009 - 11:29 AM

Quote:
Original post by Drilian
And I bet you have a BUNCH of information to back that statement up, right? Right? No? Oh.

This is exactly the kind of bullshit that Promit was talking about. You don't know, but rather than keep your uninformed and incorrect opinion to yourself, you decide to share it with the world like it's gospel.

Look, if you're a bad programmer, your code is going to be bad in whichever language you use. But if you're using an efficient high-level algorithm, you're going to get good performance out of either language.

The correct way to phrase your statement is "inexperienced/bad coders won't always write efficient code." Wow. What a revelation.


Your fanaticism really surprises me. The things that I mentioned was no more than my observations, not facts, and I believe I didn't present them as facts. I'm sorry if I sounded like a wannabe-guru, however, I'm sure that I never stated even a bad programmer can write efficient programs in c++, though you based some part of your opinions as if I did say so.

Although c# is not interpreted (not in the sense that java is), at least some part of the code gets compiled/optimized at the runtime, decreasing performance. Not even mentioning the memory inefficiencies (OK I admit these can be insignificant for some applications, and for some they are obviously not).

After all, I demand you show my ideas a little respect while still criticizing them, if that's not asking for too much.

P.S. Also I never stated that c# code is slow. Speed is a relative thing and I just said c# code will always be slower than c/c++ code (if both are optimal), which I still think is true.

#47 Promit   Moderators   -  Reputation: 6143

Like
0Likes
Like

Posted 04 March 2009 - 11:32 AM

Quote:
Original post by xylent
Although c# is not interpreted (not in the sense that java is), at least some part of the code gets compiled/optimized at the runtime, decreasing performance.
As far as I'm aware, this is more descriptive of Java (which hasn't been strictly interpreted on the official Sun runtime for many years now, but uses a dynamic JIT compiler selectively based on some memory/performance heuristics). C# allows various modes of operation; the typical choice for high performance applications is to fully precompile the intermediate code when the program is installed to the machine.

So no, it is not necessarily compiled at runtime, unless you want it to be. (There are pros and cons to both approaches, but that is a different discussion for a different time.)

#48 osmanb   Crossbones+   -  Reputation: 1462

Like
0Likes
Like

Posted 04 March 2009 - 11:36 AM

Wow. I really can't believe some of these comments. (Well, I guess I can...). Why do we use C++ at major game companies? Because we have to. Not because of performance, or because we all think C++ is awesome, or we want to prove how cool we are because we know C++. It's because on console platforms, there is really only one option. We get C++ toolchains from the hardware vendors, and that's it. Even if we wanted to use C#, it's impossible, because both 360 and PS3 use memory protection to make generating code physically impossible. Thus, we can't JIT.

Any other stupid reason you might think is pretty much irrelevant. Many of us would LOVE to be using C#. We use C# for most of our tools. But momentum (as was mentioned before), combined with the fact that there really isn't another option that actually works for our target platforms sort of makes the decision for us.

#49 Intrawebs   Members   -  Reputation: 100

Like
0Likes
Like

Posted 04 March 2009 - 11:54 AM

Quote:
Original post by osmanb
Wow. I really can't believe some of these comments. (Well, I guess I can...). Why do we use C++ at major game companies? Because we have to. Not because of performance, or because we all think C++ is awesome, or we want to prove how cool we are because we know C++. It's because on console platforms, there is really only one option. We get C++ toolchains from the hardware vendors, and that's it. Even if we wanted to use C#, it's impossible, because both 360 and PS3 use memory protection to make generating code physically impossible. Thus, we can't JIT.

Any other stupid reason you might think is pretty much irrelevant. Many of us would LOVE to be using C#. We use C# for most of our tools. But momentum (as was mentioned before), combined with the fact that there really isn't another option that actually works for our target platforms sort of makes the decision for us.


Thank you so much for this answer. It was sort of the obvious answer that I didn't want to assume as we all know what assuming leads to.

Interesting though osmanb, it sounds like this will always be the case. I can't see Nintendo or Sony having the .net CLR running on their consoles. It seems C++ will be around for a very long time (unless MS somehow manages to dominate the console market).

#50 Drilian   Members   -  Reputation: 1025

Like
0Likes
Like

Posted 04 March 2009 - 12:02 PM

Quote:
Original post by xylent
Although c# is not interpreted (not in the sense that java is), at least some part of the code gets compiled/optimized at the runtime, decreasing performance. Not even mentioning the memory inefficiencies (OK I admit these can be insignificant for some applications, and for some they are obviously not).


Promit effectively covered this one; in many cases, by the time your app is running, it's already completely in native code, so you don't necessarily lose performance to the compiler at all.

And, you keep mentioning "memory inefficiencies." Both C++ and C# have memory inefficiencies; they're just in different places. You have to treat them differently.

Calling "new" in .NET, especially on reference types, is FAST. It's effectively adding to a pointer. You can generally do it at runtime with a very minimal (potentially no) performance hit. And unless you hit one of the high-generation garbage collections, the GC isn't much of a bottleneck either.

Now, it does take some work to not trigger a heavy garbage collection, but really, in C++, you're generally doing work to not allocate anything at all during a game's runtime. If you follow the same approach in C#, you'll get similar results.

C# is seen as slower because people try to take the same lessons they've learned in C++ and apply them directly to C#. I wouldn't advise manipulating memory in C++ the way that you'd want to do it in C#, so why do people think that doing it the other way around is any better?

Quote:
Original post by xylent
P.S. Also I never stated that c# code is slow. Speed is a relative thing and I just said c# code will always be slower than c/c++ code (if both are optimal), which I still think is true.

...and which there's not really any data to support. In the many C# apps that I've worked on (including a port of a previously-C++ game, and a current game-in-progress), I have never run into a case where my code is running notably slower than a similar algorithm would in C++. Ever. Granted, there are a few places where I've had to modify my memory access patterns (away from the "common wisdom" approach that I would have used in C++), but my code still runs as fast as I'd expect it to, had I written it in C++ (and in the case of the game port, I *HAD* written it in C++).

I'd respect your statements and beliefs more if they were based off of anything more than pure hearsay, but that's not the case to the best of my knowledge. If you have any hard data backing up what you're saying, I'd be happy to take a look at it.

#51 xylent   Members   -  Reputation: 100

Like
0Likes
Like

Posted 04 March 2009 - 12:13 PM

Quote:

Assemblies contain executable code in the form of Intermediate Language (IL) instructions, and symbolic information in the form of metadata. Before it is executed, the IL code in an assembly is automatically converted to processor-specific code by the Just-In-Time (JIT) compiler of .NET Common Language Runtime.


The above quote is directly copied from C# Language Specification 3.0 Document. Apparently this is how most c# programs are intended to run. The native assembly thing you are talking seems to be an extra feature of Visual Studio or other external tools, I don't know. But Java can also be compiled to native code when you sacrifice platform independence, so I'll take those as exceptions (you may not do so).

Quote:

I'd respect your statements and beliefs more if they were based off of anything more than pure hearsay, but that's not the case to the best of my knowledge. If you have any hard data backing up what you're saying, I'd be happy to take a look at it.


Both of our opinions are based on our observations and experiments. I haven't seen you come with any hard data so far either, maybe I just missed. So what makes your experiences more valuable than mine? I hope you see where this issue boils down to? I know I haven't addressed all points in your post but I see no point in doing so as it will bloat this thread even more than it is now.

#52 Promit   Moderators   -  Reputation: 6143

Like
0Likes
Like

Posted 04 March 2009 - 12:18 PM

Quote:
Original post by xylent
Quote:

Assemblies contain executable code in the form of Intermediate Language (IL) instructions, and symbolic information in the form of metadata. Before it is executed, the IL code in an assembly is automatically converted to processor-specific code by the Just-In-Time (JIT) compiler of .NET Common Language Runtime.


The above quote is directly copied from C# Language Specification 3.0 Document. Apparently this is how most c# programs are intended to run. The native assembly thing you are talking seems to be an extra feature of Visual Studio or other external tools, I don't know.
It's built into the Microsoft implementation of the runtime; Mono supports it as well. Note that the standard doesn't say at runtime, it merely says before execution. It's practically a statement of the obvious -- IL doesn't run.

#53 Josh Petrie   Moderators   -  Reputation: 2956

Like
0Likes
Like

Posted 04 March 2009 - 12:19 PM

Quote:

I believe that we can say it is easier to write slow (resource inefficient, in general) programs to write in languages like c# not solely because of the language itself but also because many c# programmers tend to think that the .NET (or whatever underlying platform) will handle too much for them whereas many c++ programmers know that they have the control, hence are responsible for certain things.

I would disagree, but I think you're getting warmer.

C++ doesn't by itself give you much in the way of control. Remember that C++ defines its own abstract machine -- it's own definition of what, exactly a byte is, and what memory is, and so on. Just like the CLR. The difference is that C++ leaves huge swaths of that abstract machine undefined or implementation defined. This is one of the reason we tend to recommend against C++ for beginners, because this is a massive drawback of C++. However, in the right contexts, it's also a huge benefit. When you combine all the implementation-defined bits with an extremely fixed platform (console, embedded system) and some documentation on how that implementation-defined behavior works, you get a fair modicum of control -- in these very isolated scenarios, you get the 'low level' ideal that many people believe C++ gives you overall. But only in these scenarios.

These scenarios are useful for console developers -- working on the GBA, for example, involves loads of implementation defined behavior -- you cast specific addresses to pointers and write to them, which anywhere else is broken code. But the platform implementing C++ on the GBA assures you that these memory locations are mapped to suitable hardware memory registers.

A lot of the problems arise because surprisingly few people actually realize what's going on there, and where the boundaries all lie, and as such extrapolate from the basis that 'it works like this on my machine' to 'C++ says it works like this.' Some even take so far as 'computers work like this,' which is wrong. Those are often the guys who you see claiming C# and such are nonviable because they don't "have pointers" (disregarding C#'s unsafe-mode access to pointers, for a moment) while failing to realize that its referential semantics they're really thinking of. Et cetera.

Those guys (who in my observations are often C++-only or otherwise very heavily-C++-focused) do tend to write poorly performing C# code, or otherwise poorly performing code in other languages, because they have yet adapted to the idea that different contexts call for different actions to achieve optimal performance.

C# and the CLR don't magically make all your resource management needs go away, for example. The GC typically handles memory, and nothing else, leaving you to manage other resources (file handles being the common example) yourself. And lack of widespread deterministic scope-based cleanup makes this more difficult, sometimes, than in C++.

C# and the CLR are not a silver bullet. To write optimally performing C#, you need to work at it, you need to understand your domain. This is no different from in C++ or any other language. The reasons many people find C# to be more optimal in terms of development time tend to be due to it providing better, higher level features and more modern concepts (of which the GC is just a small part). Not because of memory management and other things which the programmer must 'control' and 'manage' when writing native code (although of course, not having to do that is a boon, since often native implementations end up looking very similar to many of the things GCs do, such as pooling).

Writing code from the hip where performance isn't a concern one way or another is about as easy in C# and C++, as long as you know both languages well and are only talking about the handling of those things like memory -- std::vector goes a long way. It's usually the higher level stuff that really makes C# shine in terms of development efficiency.

Quote:

Both of our opinions are based on our observations and experiments. I haven't seen you come with any hard data so far either, maybe I just missed. So what makes your experiences more valuable than mine? I hope you see where this issue boils down to? I know I haven't addressed all points in your post but I see no point in doing so as it will bloat this thread even more than it is now.

I think you're unfairly conflating things here. Drilian's challenge to you vis-a-vis hard facts was (or appears to have been) in direct response to your assertion that I quoted above in this post, and responded to. For that you have no factual basis (and in fact have several facts slightly off-base, as I noted).

[Edited by - jpetrie on March 4, 2009 6:19:07 PM]

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#54 DevFred   Members   -  Reputation: 836

Like
0Likes
Like

Posted 04 March 2009 - 12:30 PM

C++ is a bad language for beginners, because beginners are not the target audience of C++. There's too many things you can get wrong without the compiler or the runtime system telling you exactly what it is. Experts don't get these things wrong, but beginners do.

#55 Drilian   Members   -  Reputation: 1025

Like
0Likes
Like

Posted 04 March 2009 - 12:45 PM

To clarify:

I'm not arguing that C# can't be slower than C++. I'm arguing that it is not ALWAYS slower, as many people seem to be stating. Good C# can be within the same performance ballpark as good C++ (i.e. close enough that the difference, positive or negative, between the two is negligible), even with something as performance-sensitive as games.

My assertion is logically weaker by definition (not to be confused with factually weaker). It's a "can be" rather than "always." "Always" is a ridiculously difficult position to demonstrate, hence my insistence on evidence.

As per my evidence, I cannot actually PHYSICALLY SHOW YOU (mostly because I've since partially-dismantled my port to try to add some features and never got around to finishing), but when I ported Mop of Destiny from C++ to C# (XNA, specifically, and when I say "ported" I really mean "rewrote the whole freaking thing from the ground up"), the game ran at the same rough speed when framerate limiting was disabled (+/- 20fps, in the 1500fps range, i.e. the game itself was running REALLY. FAST. as it's written to run at 60). I feel like this is an apples-to-apples comparison. Code written in C++, and code written in C#, using the same algorithms, each one written as best as I could in the given language.

Hence, my assertion of "C# and C++ perform CAN roughly the same, when care is taken in both."

The assertion I'm specifically challenging, however, was:

Quote:

...c# code will always be slower than c/c++ code (if both are optimal)


Which would require a substantial amount of backup. Since it's not likely that you HAVE a substantial amount of backup (and because I feel like I have a fairly good counter-claim), I believe that assertion to be false.

Quote:
Original post by DevFred
C++ is a bad language for beginners, because beginners are not the target audience of C++. There's too many things you can get wrong without the compiler or the runtime system telling you exactly what it is. Experts don't get these things wrong, but beginners do.

I can tell you, based on code that I've seen (and, regrettably, written), that non-beginners can (and do) make the same mistakes that beginners can (and do), regardless of skill level. "Only human" and all that. :)

#56 LachlanL   GDNet+   -  Reputation: 508

Like
0Likes
Like

Posted 04 March 2009 - 12:56 PM

To reply to the OP, I would suggest that you do not try to plunge into both Cpp and game programming at the same time (as a beginner). Since you have a basis in C#, you will find learning the specifics of game architecture with it much faster than if you are also wrestling with Cpp. Even if you were experienced in both, I would suggest C# (as I have used both) for learning as it is just that much more productive.

You will find that your messing around with example apps and small demos to be a much quicker and clearer experience with C#, as you will be spending less time wrestling with mysterious memory allocation issues and any of the other gotchyas that Cpp introduces. C# is more than adequate to allow you to learn the skills needed for game programming. Once you have these skills down, there's absolutely no reason why you can't learn and switch to Cpp if you wish to "mix it with the big boys".

I guess the basis of my argument is that I think taking on game programming and learning Cpp simultaneously will take MUCH more time than learning them sequentially.

There's my $0.02AUD. [grin]

#57 Telastyn   Crossbones+   -  Reputation: 3724

Like
0Likes
Like

Posted 04 March 2009 - 01:11 PM

Quote:
Original post by DevFred
Experts don't get these things wrong


Not in my experience...


#58 MrDaaark   Members   -  Reputation: 3539

Like
0Likes
Like

Posted 04 March 2009 - 01:45 PM

There are lots of reasons to use C#.

I use it because I got tired of the things I didn't like about C++, and C# is what I always wanted, a simpler C++.

I use it because I get things done a lot faster, and I have fun doing it.

I use it because I can make my own games that run good enough for me, and then later I can sell them in the XBOX Live shop if I want. As opposed to trying to get a job in a bigger company and working on someone else's stuff.

I use it because I can gloss over the technical details of getting all the core systems running like video, sound, input, timing, and whatever else I am forgetting.

Beginner should use it because it's a great IDE/API combo, and there is a ton of domain and API specific tutorials and books for it.

It can be a lot easier to get help. When you post on the XNA forums, everyone is using the same API, IDE, Controller, Platform, etc. All techniques you read about are immediately usable and don't have to be translated to a new API's way of doing things.

There are a ton of tutorials, starter kits, and developer blogs, all XNA specific.

#59 SimonForsman   Crossbones+   -  Reputation: 5806

Like
0Likes
Like

Posted 04 March 2009 - 02:25 PM

Quote:
Original post by Bru
Quote:
Original post by Imgelling
"but also the fact that c# is bound to windows"

That is not a fact, http://mono-project.com/Main_Page

tbh even if you can use this mono thing to run .net stuff on non windows systems, you can still say c# is bound to windows. if you make a serious and big game i am not sure you want to make the clients install stuff like that(beside i am not sure its if its very legal advertise mono with your game this way.
dont think i am a complete idiot, i am not talking with confidence just what i belive might be true.


Mono is installed by default on many modern Linux distributions (not all), for those that doesn't have it you can simply add it as a dependancy in the package system and it will be dealt with automatically. For Mac i don't expect things to be that much harder.

As far as the legal part of things, just read the Mono and Microsoft section here:
http://mono-project.com/FAQ:_General

It seems as if Microsoft are extremely open when it comes to C# and the CLI, the only thing that would make them more open would be if they decided to give away the code to their own implementation.
(They won't do this though, not as long as they're able to keep their own implementation competetive)

MS .NET is ahead of mono both in features and in performance, but this is no different than Microsofts C++ compiler being ahead of gcc/g++ and shouldn't be a major issue.

#60 zedz   Members   -  Reputation: 291

Like
0Likes
Like

Posted 04 March 2009 - 02:36 PM

these are my favourite threads :)

Quote:
Which would require a substantial amount of backup. Since it's not likely that you HAVE a substantial amount of backup (and because I feel like I have a fairly good counter-claim), I believe that assertion to be false.

actually the chief inventor of C# himself claims that c# is slower (you can find a link to this in one of previous posts or have a google)

heres a piece from one of the few commercial games I know written in c#
Quote:
A lot of times the natural expressions you'd want to use when programming in C# will cause unseemly hitches when garbage collects on the 360, and you're probably going to want to multithread what would, if you had written in C++ in the first place, probably run fine entirely on one core.
The end result is the time you save prototyping and getting up-and-running in the first place can be lost in working around performance later.


http://www.gamasutra.com/view/feature/3796/postmortem_torpex_games_schizoid.php?print=1




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS