• 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

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.
0

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by DevFred
Experts don't get these things wrong


Not in my experience...
0

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Well, growing pains are inevitable. I've seen first hand what .NET's JITter can't do, because SlimDX has been smacked upside the head more than once by unexpected performance issues. God damn properties...

On the Xbox 360 specifically, the garbage collector is fairly poor, yet idiomatic C# code tends to be focused around frequent small allocations. Basically, writing C# code like you would on PC gets you into trouble, and it sucks if you don't know that beforehand. But is it any different than anything else? I mean feed the 360 some naive C++ collision code the first time through and you'll probably be horrified by how long it actually takes to run.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by zedz
heres a piece from one of the few commercial games I know written in c#
'written in C#', but there are other details, like the fact that's it's running on the 360's version of the .net compact framework, which is slow in some areas like GC, and floating point performance.

That's not a C# issue, as much as it's an issue of someone making their first game on a new platform with a specific runtime's issues. The GC issue itself can be almost nullified just by loading everything upfront, and minimizing allocations after that.

Floating point is just something you have to deal with an design around.

Remember, a poor artist blames his tools. ;) Work around the bottlenecks and minimize them.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by LachlanL
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]


I thought about this, and, it would make the transition an easy one. However, I don't mind going through the growing pains of learning c++ at the same time. I did some level design for Serious Sam looong ago and have followed game dev since Epic and ID started to battle it out (even did some Unreal Script).

At an abstract level I have a good grasp on all the components necessary just no implementation skills at the c++ level. You gave great advice though and summarizes the fence I've been on.


0

Share this post


Link to post
Share on other sites
Quote:
Wrong. C# is not "tied to Windows' in any way, shape, or form -- no more than C or C++ are. C#, like C, like C++, is standardized by a third party body (ECMA, in this case). Microsoft has people on the advisory board for the standardization committee, but they do the same for C++ as well. So, that's a wash.

Except Microsoft doesn't hold patents for C or C++.
There are patents you are required to infringe to provide an implementation of C#.

As for C++, it's simply a misunderstood language. You can tell by the amount of code that doesn't follow RAII and isn't exception-safe (i.e. the amount of code that is utter crap).
I say, better use C# than use C++ badly.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by loufoque
Quote:
Wrong. C# is not "tied to Windows' in any way, shape, or form -- no more than C or C++ are. C#, like C, like C++, is standardized by a third party body (ECMA, in this case). Microsoft has people on the advisory board for the standardization committee, but they do the same for C++ as well. So, that's a wash.

Except Microsoft doesn't hold patents for C or C++.
There are patents you are required to infringe to provide an implementation of C#.

As for C++, it's simply a misunderstood language. You can tell by the amount of code that doesn't follow RAII and isn't exception-safe (i.e. the amount of code that is utter crap).
I say, better use C# than use C++ badly.


Microsoft holds patents that covers pretty much any application that goes beyond "Hello World", the same is true for most of the large software companies, as far as .net and mono goes:

Quote:

http://mono-project.com/License

Could patents be used to completely disable Mono?

First some background information.

The .NET Framework is divided in two parts: the ECMA/ISO covered technologies and the other technologies developed on top of it like ADO.NET, ASP.NET and Windows.Forms.

Mono implements the ECMA/ISO covered parts, as well as being a project that aims to implement the higher level blocks like ASP.NET, ADO.NET and Windows.Forms.

The Mono project has gone beyond both of those components and has developed and integrated third party class libraries, the most important being: Debugging APIs, integration with the Gnome platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, extensive database support (Microsoft only supports a couple of providers out of the box, while Mono has support for 11 different providers), our POSIX integration libraries and finally the embedded API (used to add scripting to applications and host the CLI, or for example as an embedded runtime in Apache).

The core of the .NET Framework, and what has been patented by Microsoft falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA, (he is one of the inventors listed in the patent): here (http://web.archive.org/web/20030424174805/http://mailserver.di.unipi.it/pipermail/dotnet-sscli/msg00218.html)

Basically a grant is given to anyone who want to implement those components for free and for any purpose.

For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.

Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono.

The patents do not apply in countries where software patents are not allowed.

For Linux server and desktop development, we only need the ECMA components, and things that we have developed (like Gtk#) or Apache integration.


I don't think we should assume that Microsoft will go back on their word, the only parts of mono that could be potentially dangerous would be those that aren't covered by the standard. (These suffer from exactly the same issues when it comes to US patents as any other software)
0

Share this post


Link to post
Share on other sites
Note that standardization with the existing bodies (ISO in particular) imposes requirements on how patents work, in order to ensure that competitors can implement those standards. A company could never sue you via patent law on something they've gotten standardized.
0

Share this post


Link to post
Share on other sites
I moved over from c++ to c# because of a few reasons...
- no writing headers
- intellisense works
- it compiles faster
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Ashkan
Another language war.
I'm overjoyed!


Ya, only a couple posts actually addressed the post subject line as to why c++ seems to be in the industry job postings vs. c#.
0

Share this post


Link to post
Share on other sites
C++ or C#, it probably doesn't matter. From the limited experience I had with my Breakout Game I could say that the code used for the C# Game would pretty much work as is in a C++ Game, except for relying on the Garbage Collection.

For this reason C# provided me with a very simple way of implementing what I wanted with minimal fuss. With C++ I would have been required to delete and delete[] my way out of the Wall or I would be Hemorrhaging Memory before long.

From a Beginner perspective, C# is the way to go for simplicity and ease of use. Moving from C# to C++ isn't all that difficult, so I wouldn't be too concerned about potential in the Games Industry. As long as you show an aptitude for crafting Algorithms to achieve your tasks you should be able to get a job in these areas.

Also, once you have become proficient with a language you can always move to another one, like C++, to see if it suits your needs. Why have to be weighed down by the Memory Management Overhead in your code in C++ when you can simply assign pointers to null in C#? Especially when you are trying to concentrate on more important Game matters instead.

Just my $0.05

- dwarfsoft
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Intrawebs
Quote:
Original post by Ashkan
Another language war.
I'm overjoyed!


Ya, only a couple posts actually addressed the post subject line as to why c++ seems to be in the industry job postings vs. c#.


Will someone think of the Mac/iPhone developers??
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Intrawebs
Quote:
Original post by Ashkan
Another language war.
I'm overjoyed!


Ya, only a couple posts actually addressed the post subject line as to why c++ seems to be in the industry job postings vs. c#.


I think this is primarily from a history perspective. Games have predominantly been programmed in C++. Therefore, assuming code re-use, C++ is the primarily adopted language. Also, the language is not necessarily decided upon by the Developers, but often by Management - again this could be Historical in nature.

Nothing wrong with C++, but certainly there are other options. I think its just market inertia that is preventing a lot of them branching into other fields, especially if they already house the technical genius in C++.

Just a thought.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Intrawebs
Quote:
Original post by Ashkan
Another language war.
I'm overjoyed!


Ya, only a couple posts actually addressed the post subject line as to why c++ seems to be in the industry job postings vs. c#.

And this is why these types of threads should be shut down on sight by moderators/staff. They almost always (I've never seen one that hasn't) end up turning into irrational pissing contests where many people post more bullshit than fact. Sadly these things often become another source for "the truth" for yet more people wishing to argue their side in their religious crusade.
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.

Even if we accept the basic premise that C++ code has the potential to be faster, what the hell does it matter to someone just starting out that an experienced professional developer (or more likely a team of them) can eke out slightly more performance in the end? It doesn't, and you do a disservice to this community when you say things like that.

On the bright side, there are lots of people around to correct these problems, so there's no worry of someone making the mistake of believing you.

What exactly are you trying to say here? C++ compiled code is faster, but it is not important for fresh developers? Or you want to say that C++ compiled code is not faster than software running on top of VMs?
0

Share this post


Link to post
Share on other sites
Quote:

What exactly are you trying to say here? C++ compiled code is faster, but it is not important for fresh developers? Or you want to say that C++ compiled code is not faster than software running on top of VMs?

The whole point of the 'language war' aspect of this thread was to indicate that such blanket statements like "X is faster than Y" are bullshit blanket generalizations.
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