Jump to content

  • Log In with Google      Sign In   
  • Create Account


Is there any chance of C# bieng adopted by the AAA game studios, as a replacement to 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.

  • You cannot reply to this topic
65 replies to this topic

#21 ApochPiQ   Moderators   -  Reputation: 14103

Posted 03 December 2012 - 07:23 PM

.Net isn't going anywhere. The "C++ renaissance" thing is just a ploy to cater to people who think C++ is the only language you can use for "real programs."

Sponsor:

#22 Icebone1000   Members   -  Reputation: 970

Posted 04 December 2012 - 06:04 AM

this is so scary..I dont want get old and programming in c++ just because I like it and having no real motive to.. T_T me like c++ so much

#23 way2lazy2care   Members   -  Reputation: 782

Posted 04 December 2012 - 07:35 AM

I hope this is the case, but I'm not as confident as you are. MS are no longer pushing .net the way they were. Look at the failure of WPF, and the subsequent return to C++ in winRT.


Why was WPF a failure? It probably won't be used much anymore, but programming for windows 8 is pretty similar to WPF, and would probably still be considerred WPF if they hadn't made winRT so compatible with .Net.

#24 ChaosEngine   Crossbones+   -  Reputation: 2101

Posted 04 December 2012 - 02:14 PM


I hope this is the case, but I'm not as confident as you are. MS are no longer pushing .net the way they were. Look at the failure of WPF, and the subsequent return to C++ in winRT.


Why was WPF a failure? It probably won't be used much anymore,


How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.

programming for windows 8 is pretty similar to WPF, and would probably still be considerred WPF if they hadn't made winRT so compatible with .Net.


There are some similar concepts, but I think replacing the entire runtime and api of a library can be considered to be a "new axe". But the most important difference is that WPF was a managed library from the ground up. From a win32 perpective it was one owner drawn window that managed everything internally. WinRT is not managed.


Good overview of the history here.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#25 Memories are Better   Prime Members   -  Reputation: 769

Posted 05 December 2012 - 02:17 AM

How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.


No offence but this (as you probably already know) is a lot like the many many (far too many) whiny comparison threads between WPF and WinForms over the years (no different from the annoying C# vs C++ ones either), which almost always gets resulted in links to http://msdn.microsoft.com/en-us/library/aa970683.aspx or something VS2010 related. The extra features it has are not only overused but are likely the reason why so many people complaint about performance; element collisions, multiple effects on elements, effects created on the CPU, animations, animated layout, using media element, 3D content on the CPU are just some of the 'features' that are badly abused, it was almost like people thought WPF was used to make over pretty UI controls that were no different from game entities then apply collision and other pointless crap to them.

WPF gets considered complex, on other forums this may make sense but on a gaming forum WPFs learning curve is a small fraction of what people would have to learn to make even the simplest game, not that it makes any difference since Windows 8 uses XAML so any complexities would be unavoidable if they moved onto Windows 8 anyway.

As for your 'getting simple things right' comment, I am eager to hear what you were trying to do and how you achieved it. Now I have only been using WPF / SL / WinForms for 2 years (although that doesnt mean much since total years != total hours) and while I use all three for different things, my decision is NEVER based on memory consumption mainly because any visible lag is my own coding error and it would seem all the memory complaints after .Net 4 were to do with visual effects. If anything the only resource drainage is from XAML editor in Visual Studios, something that is non-existent in Blend

Besides if you read up on current performance issues, it is almost always to do with effects, media, animations, ink canvas effects or some other eye-candy thing that typically you wouldnt really want to do on the CPU anyway, all which can and should be done using surface sharing via SharpDX / SlimDX. I think the issue with WPF is MS advertised it as a framework for making over the top pretty apps with animations and 3D effects both of which I would never recommend doing directly from WPF.

Edited by Dynamo_Maestro, 05 December 2012 - 03:27 AM.


#26 way2lazy2care   Members   -  Reputation: 782

Posted 05 December 2012 - 11:04 AM

How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.

We're slowly switching all of our in house tools to WPF because it is more performant than winforms.

#27 ChaosEngine   Crossbones+   -  Reputation: 2101

Posted 05 December 2012 - 02:41 PM

I don't really want to derail this thread more than it already has been. Suffice to say I worked on a LOB app with WPF for over 3 years, so I'm not just making this stuff up.
If you're still keen to discuss WPF, PM me or start another thread.

I'm more interested in ApochPiQs assertion that C++ is being pushed as some sort of sop to C++ programmers. I'm really not sure of that. MS are even pushing another C++ extension (C++/CX) as the best way to develop for win8.

I suppose my concern is part of a wider uncertainty in the industry, and specifically Microsofts position in it. No-one really knows how people are going to compute in the future. Looking at the industry now, it seems pretty clear that the trend is all away from the desktop and splitting between "apps" and the web. But at some point, this is going to start affecting the enterprise sector (it probably already has with the release of Win8). It will be very interesting to see what the demand is in the next few years. Are people going to demand a rework of productivity apps to move to web/touch or will we see people decide that old school kb/mouse desktop apps are what lets them get work done?

Games and engines will be indirectly affected by this due to language support and tooling.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#28 3Ddreamer   Crossbones+   -  Reputation: 2902

Posted 05 December 2012 - 09:38 PM

Laptops are here to stay. The sales of them may go up or down, but the devices are so much more capable than any other mobile device that I am convinced about their long term slow steady growth. I believe that more people will realize the keyboard, bigger screen, gaming, and other advantages of the laptop computer over other mobiles once the realization arrives in people.

Apple and all the others will release more mobiles and consumers will play more games on them - long term, is my prediction. Microsoft has planned for this probability, don't you think? This is part of the reason why C++ is being pushed. Most of the establishment uses C++ and it fills a gap while other technologies continue progressing. The competitors will not wait for a Microsoft response and cross-platform gains are an immediate threat to market share. It is ironic that Bill Gates is rumored to have once said something along the line of games have no business being played in a PC, yet the PC is a proven area where games can be marketed and sold as an advantage for Microsoft. After Bill Gates stepped down, we saw the C#/XNA cycle and now we see a C++ one - both motivated in response to competitors, I believe. Another thing to remember is that there are in general many C# programmers in the world which will always spill into the game development genre.


Clinton

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#29 ranakor   Members   -  Reputation: 439

Posted 06 December 2012 - 04:21 AM

I don't really want to derail this thread more than it already has been. Suffice to say I worked on a LOB app with WPF for over 3 years, so I'm not just making this stuff up.
If you're still keen to discuss WPF, PM me or start another thread.


I've pretty much only worked on WPF (LoB apps too) for years and found it crazy fast, but we didn't go for any "fancy new looks", just for the nice programming models it allows through MVVM. Switching to that from web (i wasn't doing web before, but i suggested we switched internal LoB apps from webforms to that) boosted productivity close to 10X (yes really) and the only performance issue i ever had with WPF was the about 1 second application startup time, everything else was a breeze both from a programming speed standpoint and from a runtime speed one. I'd be curious to know where you've ever hit speed issues.
Also what's important in WinRT's similarity to WPF is that it's the same as not droping WPF, porting from WPF to WinRT is beyond trivial, so there's none of that usual huge cost to switch. It also goes a lot in favor of .net, saying "well .net is the clear winner, look now you can access it from JS & C++ too because we feel it was so good" to me that sounds like pushing .net, under another name, not like going back on it. Microsoft definately seems to be strongly pushing the .net & WPF ideas forward, renaming them is a detail, and making them available through more languages is a very good bet!

#30 sankrant   Members   -  Reputation: 121

Posted 06 December 2012 - 04:51 AM

Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche.

Creating a Game is a different matter, and C# can be efficiently used in that domain...

#31 ranakor   Members   -  Reputation: 439

Posted 06 December 2012 - 05:04 AM

Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche.

Creating a Game is a different matter, and C# can be efficiently used in that domain...


And unity's been proving that pretty well.

#32 sankrant   Members   -  Reputation: 121

Posted 06 December 2012 - 05:57 AM


Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche.

Creating a Game is a different matter, and C# can be efficiently used in that domain...


And unity's been proving that pretty well.


Yeah, That's how it is done. And I don't see this changing any time soon... The game engines will have to get more fine tuned (thus C++), and the game itself will need to get better productively engineered (thus C# or more productive things).

People will use the right tool for the job, and will have fun. :)

PS: Game Engine != Game. Both are engineered differently and require different kind of skills. (C++ and C# respectively in this case)

#33 ranakor   Members   -  Reputation: 439

Posted 06 December 2012 - 06:45 AM

What's funny is that 3 little additions to C# (maybe more, but 3 i can immediately think of) could keep all the C# advantages and remove the needs for the bits of C++
- Bringing support for new instruction sets faster
- Support for compiler intrinsics in C# code
- More control over CG management (ability to manually manage the GC arrays / ability to defragment the LoH)

#34 sankrant   Members   -  Reputation: 121

Posted 06 December 2012 - 06:56 AM

What's funny is that 3 little additions to C# (maybe more, but 3 i can immediately think of) could keep all the C# advantages and remove the needs for the bits of C++
- Bringing support for new instruction sets faster
- Support for compiler intrinsics in C# code
- More control over CG management (ability to manually manage the GC arrays / ability to defragment the LoH)


I agree to this point, but it's highly unlikely.
Also, it will give you another C++, which is not required.
C# is looked upon as an enterprise solution by the majority. No Chance.

The ring has only one master, and that's C++. If the ring gets to C#, it will lead to the rise of *yet another dark lord*

Let C++ and C# remain the best tools in their own domain. (game-engine and game respectively)

Edit : Creating Game Engines require low level programming, thus C++ is the haven and heaven there.

#35 3Ddreamer   Crossbones+   -  Reputation: 2902

Posted 06 December 2012 - 11:16 PM

That is true in general about C++ for engines and C# (or other) for games, but in the case of the languages used for scripting a game, the experience of the game developers will increase, will it not? Since game developers far outnumber game engine developers, the very skilled programmers with slowly but surely find ways - a few of them - of soaking deeper into the previously frozen tundra surface of game engine development.

The same thing happened with C++ when it was younger than its lower level siblings being used for engines. We see another set of languages today competing for higher level function in principle just like the previous period of C++ evolution did.

What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it.

If you really think deeply about it, C# is being directed by industry leaders to indeed become the game development leader to surpass C++ some day. Even if they fail at that vision, C# will almost surely be a heavy weight someday in the same ring with C++. It is a matter of growth and training - literally.

Remember to think big picture and in terms of the very real industry cycles of technological development. In the non-game world, C# is gigantic. The development software for C# is comprehensive and improving. The massive crop of C# programmers will grow to maturity, ready to harvest someday in a big way in program development. A mass that large will have a large effect, just like real world physics.


Clinton

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#36 sankrant   Members   -  Reputation: 121

Posted 07 December 2012 - 02:47 AM

That is true in general about C++ for engines and C# (or other) for games, but in the case of the languages used for scripting a game, the experience of the game developers will increase, will it not? Since game developers far outnumber game engine developers, the very skilled programmers with slowly but surely find ways - a few of them - of soaking deeper into the previously frozen tundra surface of game engine development.

The same thing happened with C++ when it was younger than its lower level siblings being used for engines. We see another set of languages today competing for higher level function in principle just like the previous period of C++ evolution did.

What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it.

If you really think deeply about it, C# is being directed by industry leaders to indeed become the game development leader to surpass C++ some day. Even if they fail at that vision, C# will almost surely be a heavy weight someday in the same ring with C++. It is a matter of growth and training - literally.

Remember to think big picture and in terms of the very real industry cycles of technological development. In the non-game world, C# is gigantic. The development software for C# is comprehensive and improving. The massive crop of C# programmers will grow to maturity, ready to harvest someday in a big way in program development. A mass that large will have a large effect, just like real world physics.


Clinton


C++ isn't going anywhere till we use/create game engines.
Do you want to know, why we switched from assembly? Productivity was only one of the reasons. The main reason was, that we changed the way we changed the way we created games. We introduced the concept of *game engines*. We started using C/C++, and we are going to use it for game engines until we see a radical change in the way we create games (maybe games withought game engines). Till then live happy. (very very long time).
Looking at a larger picture, only a *systems programming languages* like Rust or D can replace C++, if ever.

Till then (what? Eternity?) use C++ to write game engines, and use C# or your favurate language to write a cool game. I am doing that, and I do not/will not regret it :)

#37 ranakor   Members   -  Reputation: 439

Posted 07 December 2012 - 03:56 AM

Well there's nothing "System Level" about game engines, so there's no reason to need a "System programming language there", a game engine is a game engine, it's not a vidcard driver and it needs no low level access by design. But i really wish they made a C# compiler switch that allowed to go more unmanaged with no hurdles, could definately make C# replace C++ fully for game engines, however i wouldn't split where you do (game in C# and game engine in C++) even today it'd probably be closer to game in C#, game engine in C#; and a tiny subset of the game engine in a small C++ dll.

#38 sankrant   Members   -  Reputation: 121

Posted 07 December 2012 - 04:19 AM

Game Engine in C#? Humans are greedy creatures. Every inch of performance counts, and technically C++ will always outperform C#. Its one time investment!
System programming != Low level programming.

The day someone writes a C++ compiler, as optimised as the present ones, 'in C#'; that day I will say 'welcome new C++'.
Why would anyone want to create unmanaged C#? It will give the world another C++. Believe me, we won't switch from C++ in case of Game Engines any time soon.

Focus on creating games and use C# if you like.

:) PS : One day, the earth will end, and we will live on mars. But we will still remain human beings.

#39 kunos   Crossbones+   -  Reputation: 2147

Posted 07 December 2012 - 04:36 AM

What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it.


sadly I don't think it'll go that way. C++ is a very closed relative of C, the 2 can mix in the same codebase and the boundaries between the 2 become quite blurred.
C++ allowed C "engine" developers to slowly get use to it without throwing away what they had and was working.. they could experiment with a little of C++ flavor here and there without compromising the structure and without feeling unsafe about it,because they knew they could just switch back to C if and when cornered.

The problem with C# is that you can't "inline" C code into it. The boundary between the "native" side and the "managed" side is VERY defined.. devs from one side can't "play" moving stuff here or there.. everything is much more "frozen"... plus you have the marshaling cost to consider every time you want to move something around.

To make C# (or any other language) a viable option to replace C/C++ in the game engine realm you need to create a compiler that can seamlessly include .c, .cpp or .cs files IN THE SAME PROJECT (warning, I said, project, not solution) . The only language that can be fooled to do this is Go, but just because it doesn't really have a concept of "project"... perhaps D can do it? ( I am not sure).

Until then, you'll have a solid and clear division between "system code" and "game code"... and every time something has to move from here to there it's going to be a big decision with lots of implications.. this will basically leave native devs firm in their camp and managed devs firm in their camp.

I have more hopes for a C++ evolving into something more C#-ish (add modules and optional GC and you're there) than the entire world to adopt C# for everything.

Edited by kunos, 07 December 2012 - 04:41 AM.

Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#40 ranakor   Members   -  Reputation: 439

Posted 07 December 2012 - 05:25 AM

The performance issue of marshalling only applies when you , well, marshall, so it's a non issue when doing parts strictly managed and others strictly unmanaged, what matters to keep cost low is not going through the frontier often. However it could be all C# & no C++ if intrinsics were available directly from managed code, keeping the full managed goodness where you need it, it's not like it's impossible "by design", it's just missing from .net so far.




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