What is programmed in C-sharp?

[TheGreatCthulhu]

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.

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!

[About .NET on PS3:] EA had no trouble doing this with The Sims 3 The also managed it on Mac OS too!

Wow, for real?!
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!

.NET is an adequate replacement for C++ for most aspects of game development and this will only get better as time goes on.

Couldn't agree more!

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?

[Mutant_Fruit]

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.

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.

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++

[TheGreatCthulhu]

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.

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