• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Intrawebs

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

165 posts in this topic

OMG, this place is overrun by the C# horde!

For game development, my vote goes to C++ which is very obvious because most of the engines/SDKs I deal with are all written in C/C++.

You know, Bullet is written in C++. PhysX is written in C/C++.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by dlangdev
OMG, this place is overrun by the C# horde!

For game development, my vote goes to C++ which is very obvious because most of the engines/SDKs I deal with are all written in C/C++.

You know, Bullet is written in C++. PhysX is written in C/C++.


Your reply would be different if you started programming with C# first, I'm sure. Then it would read...

For game development, my vote goes to C# which is very obvious because most of the engines/SDKs I deal with are all written in C#.

That Bullet and PhysX thing...don't understand how that fits in, but oh well.
0

Share this post


Link to post
Share on other sites
Bullet also works for C#
http://www.gamedev.net/community/forums/topic.asp?topic_id=452106

So does PhysX
http://imaginary-project.net/physx-sharp/

Thats why I didn't understand why you posted them.
0

Share this post


Link to post
Share on other sites
Quote:

That's hardly true, now is it. I've made two classes in C++ to wrap mutex handling (mutex and lock class), made a construct involving a for loop and an operator bool() to allow

I think he point was more that it is possible (it's certainly not easier to grok raw assembly produced from machine code). This seems related to my point that it doesn't matter that mucking about in assembly is harder than mucking about in something Reflector produced, because hackers mastered the art of the former years ago so it's pretty easy to them anyways.

Quote:

You know, Bullet is written in C++. PhysX is written in C/C++.

Who cares what the SDK is written in, if you can still use the SDK from within your desired language? You know that good chunks of Windows and Direct3D aren't C++, right?

It's (in general) irrelevant so long as you can use the SDK.

Quote:

OMG, this place is overrun by the C# horde!

Don't make silly such statements. Correcting the misapprehensions of one who (admittedly) knows little of the subject is not indicative of being part of any kind of 'horde,' and there's no reason to put such a negative implication there.
0

Share this post


Link to post
Share on other sites
C++ vs. C# is a HOT topic these days.
I pearsonally try to keep up with both.

Here are 3 reasons I think most apps (99%!) are NOT written in .NET

1) OLD habits die hard. We learn C and C++ in school. So we become comfortably with the language. It's hard for people to try to learn a whole new (And I mean that) language like c# when they are use the old. I think that's wrong thinking if you are looking for a JOB in programming. You need to learn it ALL.

2) ABSTRACTION - This may be reason number one. If you are just staring out in programming, c# is a very abstract language. It is not as close to the machine, and so some people feel disconnected from it. C is very close to the machine.
Assembler is even closer. programming in C we feel that connection more strongly. But again I still think we need to learn it ALL.

3) There are things in c# that are just plain frustrating in c# and some people just give up and do it in C. You could argue perhaps that you just don't know enough about the language to do it. But does ANYONE really know all of it?. No , of course not. I've seen PHD's stumped by .NET.

4) C books are 200-300 pages. C# books are up to 1500 pages!. Which is easier to learn?

5) If I had to learn programming again I would still take the same path:
a) C
b) C++
c) The API
c) Assembler
d) C#
e) Java
f) ASP
ect.







0

Share this post


Link to post
Share on other sites
Quote:
Original post by Greycrow
3) There are things in c# that are just plain frustrating in c# and some people just give up and do it in C. You could argue perhaps that you just don't know enough about the language to do it. But does ANYONE really know all of it?. No , of course not. I've seen PHD's stumped by .NET.


Having worked with PhD's out of academia, I am not surprised.

Though frankly, I suspect the average C# programmer knows more about that language than the average C++ programmer does theirs. And really, the number of things that are frustrating to do in C# (bit fiddling, certain buffer tasks, certain scripting tasks) are far fewer than things that are frustrating to do in C (anything involving strings, anything involving a UI, anything involving containers).

Quote:

4) C books are 200-300 pages. C# books are up to 1500 pages!. Which is easier to learn?


That's odd. All the C++ books I know of tend to be the 'bible' sort, and even then need to be supplemented with Josuttis' Standard Library book and some of Meyers' texts. (to be fair, K&R is nice and concise, but plain C is not exactly practical for many apps [imo])
0

Share this post


Link to post
Share on other sites
Those are some good points.

I did mean c and not c++ when it came to book size. Do even get me started on c++ and all of its so called helpers ... lol

grey




0

Share this post


Link to post
Share on other sites
Quote:
Original post by Greycrow
We learn C and C++ in school. So we become comfortably with the language.... I think that's wrong thinking if you are looking for a JOB in programming. You need to learn it ALL.
QFE - I learned programming on my own, largely influenced by what I observed from the luminaries on this very forum. I started with C, Objective-C and C++, learned all of tem quite thoroughly, and moved on to Python and Java.

By the time I first took a formal programming course in University, I possessed programming skills on a par with the final-year grad students. Most students here learn only the C/C++ or Java they are taught in courses, and this often severely limits the ability to think through a problem/think outside the box.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Greycrow
C++ vs. C# is a HOT topic these days.
A rather frequent topic, and generally a silly topic.
Quote:
I personally try to keep up with both.

Good.
Quote:
1) OLD habits die hard. We learn C and C++ in school. So we become comfortably with the language. It's hard for people to try to learn a whole new (And I mean that) language like c# when they are use the old. I think that's wrong thinking if you are looking for a JOB in programming. You need to learn it ALL.

I've done FORTRAN. I had no problems learning C#. If you're stuck in the old ways, perhaps it's not that it's hard to learn, but that you’re just stuck in the old ways and resistant to change.
Quote:
2) ABSTRACTION - This may be reason number one. If you are just staring out in programming, c# is a very abstract language. It is not as close to the machine, and so some people feel disconnected from it. C is very close to the machine.
Assembler is even closer. programming in C we feel that connection more strongly. But again I still think we need to learn it ALL.

You are really no more closer to the machine in C/C++ than you are in C#. All three of them run against a reference machine that exhibits certain behaviors. Furthermore with modern things such as virtualization, virtual memory (old idea really), etc. you are quite distant from the actual hardware. The same is true of assembly as well.
Quote:
3) There are things in c# that are just plain frustrating in c# and some people just give up and do it in C. You could argue perhaps that you just don't know enough about the language to do it. But does ANYONE really know all of it?. No , of course not. I've seen PHD's stumped by .NET.

There are plenty of things in C++ that are extremely painful to learn/do.
Quote:
4) C books are 200-300 pages. C# books are up to 1500 pages!. Which is easier to learn?

C#. Because you’ll be up and running in an hour or less. Those 200-300 page books also generally start with “Learn” and end with “in 21 days.” Which is generally a prime example of exactly why C++ shouldn’t be your first language, also the C++ standard is over 700 pages.
0

Share this post


Link to post
Share on other sites
At least you all had decent computers to start on, my first language was BASIC that ran on a computer that only ran BASIC programs off those big floppy discs. After I got my next Super Computer (IBM PS/2 386 16mhz with 2meg RAM, 40meg Harddrive, 2400baud modem), moved on to Pascal w/ assembly (the days when mode 13h was king), to C, to some C++ (mostly C code with .cpp on the end), then c# and have never looked back. It was just easier for me. And that is another reason I suggest C#.

And I know I shouldn't complain about that first computer, at least it wasn't punch cards.

0

Share this post


Link to post
Share on other sites
Wow, I go have lunch and all hell breaks loose.

I think Greycow put it nicely, "we need to learn it all". Now for a beginer (which Im not to programming) I still don't know which would be best to start with. For me however, since I've been working with c# for years I will start my game dev experience with c++.

I've always felt I never had a solid foundation that all the other skills can stand on, and what better way to get that than doing something fun like game dev.

Thanks everyone!

0

Share this post


Link to post
Share on other sites
I guess, here's the thing, for me:

I have done a lot of C++. Well more than a decade of it. I work in C++ at my job. I'm fairly comfortable with it.

However, I use C# whenever I can, such as in my home projects. I haven't seen a performance penalty on my PC for using it, and even if there is one, it's minor enough that I don't care. Whatever I (hypothetcally) lose in the (hypothetical) tiny performance drop is more than made up for by the amount of work I can get done at one time.

C# is easy to work with. When I'm coding in C#, I feel like I'm working on my PROJECT, and not wrestling with the language to get it to do what I want. It generally allows me to focus on the high-level side of my algorithms instead of having to get bogged down in the details.

So say whatever you want about "OMG C# PERFORMANCE IS CRAP" or "Every professional developer uses C++ so obviously C# is crap", but for my productivity, C# is an invaluable asset.
0

Share this post


Link to post
Share on other sites
Quote:
Well, the Playstation 3, the Wii, the PSP, and DS are all still relevant. Mac and Linux aren't, for better or worse.

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 :)


[Edited by - Fiddler on March 4, 2009 4:02:34 PM]
0

Share this post


Link to post
Share on other sites
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!
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.)
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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).
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0