I just need a little help with a short paper on C#;
so, I was wondering, specifically, what kind of things are programmed in C# and can you provide
examples? Thanks
Printable View
I just need a little help with a short paper on C#;
so, I was wondering, specifically, what kind of things are programmed in C# and can you provide
examples? Thanks
Applications, Web sites, and Web services - pretty much everything.
I think it is also one of the most popular languages for video games and physics engines.
Yeah that's not true. C++ is far and away the most popular game programming language. C# + XNA is great, but you can hardly say it is one of the "most popular" languages/platforms for game development.Quote:
Originally Posted by DeepThought
That's the opposite of true. Those are two very good examples of where you should probably not code in C#.Quote:
Originally Posted by DeepThought
Oh I see it a lot on requirements for job postings. What are the advantages to C++ I can do int++ in C# as well :PQuote:
Originally Posted by BigEd781
You'll need to program in both to understand the differences.Quote:
Originally Posted by DeepThought
Quote:
Originally Posted by DeepThought
Quote:
Originally Posted by BigEd781
Quote:
Originally Posted by Chris_F
Quote:
Originally Posted by DeepThought
As for game development - mainstream games are definitively done in C++ (speed being one of the obvious advantages, a bunch of experienced C++ game programers being the other, standard C++ graphics APIs being another one, and so on...). However, on the indie scene, there's a lot of people experimenting with C#. Besides, I feel that Managed DirectX and XNA are pretty capable. There were even some (though not particularly noticeable) commercial games developed in C# - or so I've read somewhere.Quote:
Originally Posted by Arjay
I think that game programmers can greatly benefit from the C# language, and the way good C# code is written (and designed). As the hardware gets more powerful, the potential for C# to penetrate into the field of the "mainstream" game development will grow I guess.
Furthermore, there are various kinds of games, and not all of them require raw power above all other things; there are games made in Java, or Flash (ActionScript)... I mean, on one end of the spectrum are fancy 3D-HD-WhatNot-games, and on the other are text-based games.
It all boils down to what you mean by game.
But, since we're probably talking about a modern 3D engine based game here, I'm under the impression that C# can be used to create a fairly decent engine. Maybe it's not (yet) suitable for an AAA title, but things change with time. Think of what kind of games you can play on mobile phones now, and compare that to the classic Nokia Snake. Those hardware engineers will eventually come up with something that will make us forget that IL and JIT-compiling are even there.
That's a very good example of something that is wrong :)Quote:
Originally Posted by Chris_F
While I agree that .NET is not "one of the most popular" platforms for developing 3D games I'd also put it out there that C++ is about 25 years old and .NET is about 10 years old. Of course you're going to see a hell of a lot more code in C++, you can't just throw out everything you've written for previous games overnight so you can use a new fancy productive language ;) However an important factor to note is the adoption of C# over C++ for new projects is going up. The majority of the Sims 3 was done in .NET. SecondLife using .NET as it's primary scripting language. Unity3D use .NET as their primary platform for game logic development. .NET is an adequate replacement for C++ for most aspects of game development and this will only get better as time goes on.
Five years ago if someone said that a major game publisher would write a significant proportion of their game using .NET they would've been laughed out of the room. Now you can even get SIMD acceleration directly from 100% safe C# code http://tirania.org/blog/archive/2008/Nov-03.html . Did someone say super fast accelerated physics? I think so! :)
Yes, the reason C++ is so dominant is not necessarily that it is the only language capable of writing a game with, it is the fact that the *vast* majority of existing code is already written in C++. Also, in regards to console games, a language like C# is just impractical. Have fun running .NET on your PS3. Also, there are many times in which you do need direct access to the hardware, and C# is simply not designed for such things.
Writing an indie game for a Windows PC? Go ahead and use C# with XNA or DirectX. Anything else is just going to be a huge pain.
Interesting, so I take it if you write a program in C++ it does not require the framework to run.
That alone is worth using it for!
Well, no, not really. C# is a great language and the .NET framework trivializes many tasks that would be more onerous if done in C++. One language is not "better" than the other, they are different tools for different jobs.Quote:
Originally Posted by DeepThought
Do you understand the depth of penetration the .Net framework has (i.e the % of Windows systems that has one or more versions of the .Net Framework)?Quote:
Originally Posted by DeepThought
In other words, often times there is nothing additional to install to run a .Net program.
I can say with 99.9% certainty that no game ever directly accesses hardware. That's what device drivers are for :) Sure, C# is not really designed for device drivers, but that's not what you'll be doing when you're writing a game. If there is some exotic hardware you need access to you'll just access it via it's driver just the same as how you can play sounds and render 3D graphics in C# today.Quote:
Originally Posted by BigEd781
EA had no trouble doing this with The Sims 3 :p The also managed it on Mac OS too!Quote:
Have fun running .NET on your PS3.
No, not at all. A language with a framework is *far* superior to a language without a framework in every respect. Assuming a 'framework' is defined as 'a set of reusable libraries', every major language has this. What game developer wants to write their own List implementation or their own quicksort. None. They want to write game logic. Therefore the richer your framework and the easier it is to use, the faster you can get your task (writing game logic) done. With that in mind, the language with the largest framework would be the logical choice.Quote:
Interesting, so I take it if you write a program in C++ it does not require the framework to run.
That alone is worth using it for!
If by 'framework' you mean a JIT compiled language, avoiding a language simply because it has a JIT makes absolutely zero sense. The existence (or non existence) of a JIT should be completely irrelevant to you unless the platform you're targeting does not allow jitting. All that should matter to you are concrete performance targets (i.e. being able to execute at 60fps on a Core 2 Duo 2ghz with an ATI 4800) and developer productivity. If a jitted language can reach your target with better productivity than a non-jitted language then surely it's worth giving it some serious consideration.
Ok, yes, access hardware via the device driver :). But still, those interfaces are rarely friendly to access through C#, I do it for a living every day.Quote:
Originally Posted by Mutant_Fruit
Quote:
Originally Posted by Mutant_Fruit
Quote:
Originally Posted by Mutant_Fruit
Wow, for real?! :D:D:DQuote:
Originally Posted by Mutant_Fruit
I wasn't really following the new developments on "the scene" with this regard, so this is good news to me. Hell, it's music for my ears!
:thumb:
:D Couldn't agree more!Quote:
Originally Posted by Mutant_Fruit
BTW, since you seem to have some insight into the gaming industry, a question: Wouldn't nowadays game developers prefer using capabilities provided by pixel (fragment) shaders and vertex shaders and such, instead of using FPU instructions? At least in a general case? Or, maybe I'm off-track with this?
Do you mean OpenCL and similar frameworks for offloading CPU calculations to the GPU? If so this is only really usable for *highly* parallisable tasks. There is an absolutely massive latency (comparably) to get data to GPU memory, run your logic and then retrieve the result for the CPU to process. Physics calculations are close enough to this 'highly parallisable' type of task that they can run well on the GPU (see PhysX). It's also worth remembering that GPUs are stupendously slow in comparison to a normal CPU. The can just do 512 or 1024 stupendously slow things perfectly in parallel :) Stuff like video postprocessing (scaling and colour conversions) also fit this perfectly.Quote:
Wouldn't nowadays game developers prefer using capabilities provided by pixel (fragment) shaders and vertex shaders and such, instead of using FPU instructions? At least in a general case? Or, maybe I'm off-track with this?
As do I (more or less ;) ). While it's not always pleasant it's definitely doable and can make things much simpler in the long term once the driver is bound. If a particular driver/library is hard to directly bind in C# a common technique is to write a simplified wrapper in C and then bind the simplified wrapper. Pretty much every week someone on my team complains that more of our code should be written in C# instead of C++ :)Quote:
Ok, yes, access hardware via the device driver . But still, those interfaces are rarely friendly to access through C#, I do it for a living every day.
Yes, among other things. To my understanding, a modern game mostly spends it's time reducing the amount of data that needs to be sent to the GPU, transferring the data, and doing some massive hardware-accelerated texture processing and composting. OK, I guess physics can take a big chunk of the cake, too. But, as you've said, these are all things that can be successfully parallelised.Quote:
Originally Posted by Mutant_Fruit
I don't think that the AI has a terribly significant performance impact? In the age of the fixed function pipeline, game developers were hampered by what the API provided them with.
What would they do back than if they wanted to get some neat, unconventional effects? From what I had a chance to see, they would bend the rules a little to come up with neat little tricks. For example, using mipmapping to get a blur effect, and something along those lines.
I'm also guessing that if they wanted to do some unusual processing (say for textures, or physics), they would use the FPU? Maybe do a thing or two using assembly, to speed things up.
Also, for what kind of processing tasks are these things used today, in modern games?
Speaking of image processing, I've always wondered how did applications like Photoshop achieve such speed, especially in the age of PS6 or PS7?
Anyway, back to gaming: my point was - unlike C#, C++ provided and still provides ways to do these low level optimizations; but whit the emergence of these new APIs and technologies, and shader languages, C# can easily become the language of choice.
Besides, isn't it true that it's application design that has the most significant impact on the performance? If the design is wrong, there's only so much you can do to improve the performance by optimizing.
I think C#, along with the .NET philosophy of application design, can help game developers write better code.