Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Why is c# bad for games dev?

Discussion in 'General Discussion' started by Deleted User, Feb 2, 2010.

  1. Jim Offerman

    Jim Offerman

    Joined:
    Jul 17, 2009
    Posts:
    177
    While it's certainly true that most of the code in triple-A games nowadays is C++, you can expect to find C and ASM in each and every one of them.

    In part, that's for historic reasons. For example, we have various bits of ASM code in at work that just work and have worked for years. Why would we even attempt to rewrite that in C++? There's no benefit, only the risk of the C++ rewrite breaking something unexpected in the 100k lines of code that make up the engine.

    On the other hand, the attitude at most triple-A companies (that I know of) is: whatever gets the job done, is what we use. We prefer C++ (since 95% of our code is C++), but if a particular task requires hand optimized ASM, we'll use that. We may even use C# in bits of the engine, if that is what's most effective to solve a particular problem. The goal is, obviously, not to write all of the engine in a single language... the goal is to ship a quality game, on time and on budget.

    C++ hasn't been mainstream since the day Visual Basic 1.0 was released. We just happen to consider it so, because it is still dominant in the field we work in.

    That said, I do not expect C++ to go away anytime soon. Certainly not over the next decade. Another work floor example: our tools folk decided to start using C# for the newer tools approximately 3 years ago... but no one is even considering yet to rewrite the, roughly, 50 man-years worth of C++ code in our toolchain yet. I'm sure you can imagine why! ;)
     
  2. Quietus2

    Quietus2

    Joined:
    Mar 28, 2008
    Posts:
    2,058
    For the same reason that most all mid to large size enterprises still are RPG or COBOL shops.
     
  3. Per

    Per

    Joined:
    Jun 25, 2009
    Posts:
    460
    Is it that important?

    I'm a C++ developer. C++ and C# are not that dramatically different, C#'s memory management and garbage collection might result in slower performance in some situations, but if you write your code well and understand the mechanisms behind it all then you should find performance is fairly similar.

    The only thing I really don't like about C# is it's excess verbosity (do I really need to type new in front of every instance of a complex datatype? it really doesn't make things any clearer, better or faster and seems like an excuse for sloppy compiler writing to me), and it taking away some control with regards pointers and the like. But C++ can also do this and has it's own quirks.

    Lets be clear here, the only real reason why C# is bad for games is that no-one outside of the indie and XNA scene is using it. It's like why is it bad to use XSI or C4D rather than Maya or Max? It's not bad, none of these are fundamentally under-performing technologies, but if you want to get a job at one of those big companies then you'd better make sure you know the tools that they use because they aren't going to want to hire someone without those skills, or conversely if you want to hire people you'll find much larger talent pool using C++, Maya and Max professionally than C#, XSI and C4D. If that's not your aim or concern then it becomes totally irrelevant, use whatever works best for you and gets the job done.
     
  4. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,364
    Agree 100% with you. C++ still older and popular. So most of the tools and engines are C++ based.
    No one would like to rewrite its own engine from scratch in an other language. Even so, if tomorrow, turns out that C# become faster than C++ don't spect major C++ engines making the move to C#.
     
  5. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    Unreal 3 has no assembly code zero. You do not really have many AAA engines out there. Mainly unreal and maybe crytech or else its custom build and thus not really a engine.



    http://alpatrick.blogspot.com/2006/02/tim-sweeney-gives-presentation-at-popl.html

    "We never use assembly language" see page 20

    Page 57 "Garbage collection should be the only option"

    http://www.scribd.com/doc/5687/The-...-A-Game-Developers-Perspective-by-Tim-Sweeney
     
  6. SixTimesNothing

    SixTimesNothing

    Joined:
    Dec 26, 2007
    Posts:
    167
    It's interesting to note that "C++ IS A BAD LANGUAGE FOR GAME DEVELOPMENT - WHAT SHOULD REPLACE IT?" is one of the keynote presentations at GDC this year.

    http://schedule.gdconf.com/
     
  7. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    1: C# 4.0 is going to add a dynamic type.

    2: I can see more functional stuff coming in the future from F#. C# 3.0 added lambda expressions and linq.

    3: I could see mixins coming over from D to help those who want multiple inheritance.

    4: Parallelism is not solved but is being addressed.

    BAM you more or less have Tim Sweeney's perfect language. Plus it is already too late to change course now. C# will be the future. Microsoft has already decided and the groundwork has been laid.
     
    mimiCryMuffin likes this.
  8. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    I might ask for this for the very first time but could we have Ruby in Unity please?
     
  9. aaronsullivan

    aaronsullivan

    Joined:
    Nov 10, 2005
    Posts:
    986
    @MadMax
    I think you may have been dreaming. BAM - wake up now. :D

    @taumel
    lol. First, last what's the difference.
     
    sujanmishra likes this.
  10. Jim Offerman

    Jim Offerman

    Joined:
    Jul 17, 2009
    Posts:
    177
    1. Unreal 3 is not representative for all engines;
    2. There's at least a dozen competitors to Unreal and CryEngine. To name a few: id Tech, Source, Gamebryo, Renderware, Cryware;
    3. Game engine = piece of software used to develop/run games. Whether that's in-house or out-house is irrelevant. I dare you to tell the guys who made the Anvil engine (Assassin's Creed) that they can't call their engine and engine just because you can't buy it! ;)
     
  11. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    I never said that all engines would be C# or even that all C# engines would be totally C#. I said that C# is going to be relevant to AAA games as a main programming language if it is not already. I am talking PC games here not Mac not Xbox not iPhone etc. It is possible that PC games have already died out which would mess up my prediction, unless Xbox 720 is better with C#, which seems likely.

    I would not call Gamebryo or Renderware strictly AAA engines. I don't know what the hell Cryware is maybe you mean CriWare? Which I am not even sure I would call that an engine and which is really for consoles.Id Tech 4 had what one license wow what must really suck.

    Seems rather irrelevant as an engine if you cannot buy it and would not buy it even if you could.
     
  12. zander1976

    zander1976

    Joined:
    Jul 8, 2009
    Posts:
    10
    Well I don't think I would put it that way. State of the art design methods such as OO ( when was OO considered state of the art anyway) or Generic Programming, in a lot of cases, were developed in c++ or at least made popular by it.

    There are plenty of things that c++ did well and plenty that it did poorly. C# and java learned from their design and implemented it in a cleaner looking way.

    C++ did a good job paving a way to get from c to c#. C++ implemented classes and templates that led to stuff like design patterns and the STL.

    Design patterns became popular because c++ was difficult to work with but had all the power you could imagine. C# used those concept and refined them to be less cumbersome.

    Back to C++ vs C#
    Heres my list of comments you will hear:

    Allows for better design:
    You can make just as much of a mess in either language. Design is design, both languages require it.

    One is faster then the other:
    If the person knows how to code well then sure c++ could be faster and a poor programmer could produce the opposite result. C# has a higher level of understanding of what you are trying to do.

    One requires more knowledge:
    C++ requires more knowledge of what you are doing. You can't just say new ArrayList in c++ and not know how its doing its memory management. Well you can but its not going to go so well. With the same knowledge and care, c# is also a very powerful language.

    Pros and Cons
    C++ allows more memory control. In good hands this is great and in bad it's bad.

    c# has garbage collection that can cause issues. Don't delete anything and you won't run into this problem. :)

    c# does allow you to use generic programming with little to no knowledge of what it just did.

    C++ does have header files. They are a horrible mess at times but it is nice to simply read the class methods without the mess of the implementation there too.

    Conclusion
    Any good programmer knows that their is no such thing as a best language. They have their strengths and weaknesses. Pick the language that is right for the task.
     
  13. zander1976

    zander1976

    Joined:
    Jul 8, 2009
    Posts:
    10
    This sounds like the same argument that was said about ASM vs higher level languages like c. :)
     
  14. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    I agree there will be times when you want C / C++ rather then C#. However, you should not be picking C / C++ over C# purely because of performance that is dumb. We are talking about a linear time slow down (not even a order of magnitude) and computers are increasing in power in exponential time. Pick your language for its features.
     
  15. zander1976

    zander1976

    Joined:
    Jul 8, 2009
    Posts:
    10
    I am worried when people say "computers are increasing in power in exponential time". I have heard this as an excuse many times for poorly developed software. :)
    Yes, features is how I would define right. :)

    If I need to do serious text processing then Perl is nice for this.

    If I need fast application development then C# is very nice for this.

    If I need to write memory concious applications were I will write my own memory managers and profiler then I will likely lean towards c++.

    If I need mantainable code then I will still pick from the list above and try to write clean code in any language :)
     
  16. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    You have heard it before because it is true. PC games are largely GPU bound you may as well take advantage of the horsepower. As for it being an excuse for poor developed well that is a philosophical question and thus un-falsifiable.

    I do not really find anyone's opinion very revolutionary, new or even interesting. Honestly, this boring debate has been going on for years. So I must bid farewell.
     
  17. aaronsullivan

    aaronsullivan

    Joined:
    Nov 10, 2005
    Posts:
    986
    Oh. Didn't know you were in a debate, MadMax, you should have told us! We were having a discussion to help our understanding of the issue become more well- rounded. :D

    I really enjoyed Tim Sweeney's slides, myself. Hadn't thought about some of those angles before and my knowledge of Haskell and functional programming has always been pretty limited. The great news, as developers that embrace Unity is that this stuff is not mission critical for most of us for the time being. :) Leave all that to UT and concentrate on making great games.

    And can we get some Ruby in there to shut Taumel up? :p
     
  18. bpatters

    bpatters

    Joined:
    Oct 5, 2009
    Posts:
    164
    Like many people say pick the language that's best. I can see the argument that the performance difference between C# and C++ is not worth the trouble of using C++ in a lot of situations. However several people have said that C++ is slower than C# which is completely in 95% of the situations.

    Also keep in mind in todays green moving and mobile device world where power consumption is gaining increasing importance that C++ gives your significant advantage in power savings.

    My biggest problem with Garbage Collection languages is that they result in inconsistent pauses within games which are even more detrimental than the slight performance degradation. Study's have shown that something running at 25fps consistently is more well received by users than something running at 50fps with occasional drops to 25fps interleaved.

    A lot of people think, incorrectly, that garbage collection occurs in a background thread so does not effect the other threads. In truth the nature of Garbage collection requires the Thread to lock all other threads while it does it's mark and sweep stages and thus results in a perceived "thread lockup" while it performs garbage collection.

    For my game I minimized this by having a co-routine performing garbage collection every 10 seconds or so to limit the amount of memory it has to collect to keep these garbage collection pauses from adversely effecting my game. However you still have to be very aggressive about limiting your usage of strings and other objects that must be garbage collected.
     
  19. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    Yes, finally, please! :O)

    You know that something went kind of wrong for an easy to use tool when there do exist threads which are discussing the imponderables of C++ vs. C# (especially whilst leaving out lovely assembly ;OP).
     
  20. Jim Offerman

    Jim Offerman

    Joined:
    Jul 17, 2009
    Posts:
    177
    Of course you wouldn't. Can I assume then, that you also don't consider Fallout 3 (Gamebryo) and GTA: San Andreas (Renderware) to be AAA titles?

    You missed my point entirely. You appear to believe that something may only be called an "engine" if it is commercially available, I was merely trying to convey that there are lots of in-house engine developers who would not agree with you.

    There far too many PC games to make such a broad statement. And FPS like Modern Warfare is indeed very likely to be GPU bound (on all platforms). RTS titles, on the other hand, tend to be limited by the CPU(s).

    Going back to the discussion at hand, I think it simply doesn't matter! ASM, Pascal, C++, C, Objective-C, C#, Boo... whatever works best for you, is what you use. Even if you're striving to create a AAA title, the quality of your game is neither defined nor guaranteed by the language you write your code in.

    On the same chain of thought, I would also argue that the notion that you couldn't a develop AAA title using Unity is complete and utter nonsense.
     
  21. vano512

    vano512

    Joined:
    Feb 15, 2010
    Posts:
    2
    Just stop listening to "real programmers" who "use" c++/asm etc stuff for their super mega optimized AAA+A games in their dreams.

    Decide what you want to do and where you want it run.

    Pick language that is enough(as it satisfies performance and size limitations, there's no point picking C++, when target machine have 10X power, your game needs 4X if it's in C#, and it would need 2.5X if it was in c++).

    After time, after hard development cycles you'll gain enough knowledge to decide by yourself and be confident about your decisions.

    Finally what matters is the technology has to be:

    * Manageable(as much as you need)
    * Cost effective(as much as you need)
    * Scalable(as much as you need)
    * Maintainable(as much as you need)

    But this all after you have some experience.

    And for now:

    JUST DO IT!!! --> it's more important than C++ vs C# vs Javascript debate when you are just starting up. Make a mistake!

    Remember clocks are ticking...

    JUST DO IT!!!
    JUST START IT!!!

    P.S. Little recommendation: just live C++ alone for now, use Unity, can't choose between Javascript or C#, choose randomly and start doing it. IMHO
     
  22. BearishSun

    BearishSun

    Joined:
    Dec 1, 2008
    Posts:
    175
    C++ is chosen because it's MUCH faster than C# when in proper hands.

    If you try to compare some normal code C++ vs C# you won't see a real performance difference. But if you know how to use it, and make use of SSE intrinsics(or assembly if you prefer), prefetching, cache and memory alignment correctly speed increase can easily be 5x over C#. Although I am guessing here about the number, SSE alone offers 4x speed increase of any code that might use it. Using these is a must in any performance critical engine part, and those cannot be written in C# if you want state of the art engine.

    On the other hand, I use C++ and C# equally and love them both. You just gotta know when to use which.
     
  23. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    What's the point in having something like this, if you need to use an archaic programming language in order to use it? Shouldn't people be making hardware that works with programming languages that are built for usability?
     
  24. BearishSun

    BearishSun

    Joined:
    Dec 1, 2008
    Posts:
    175
    Well I was working on a custom Raytracer as a college project, using SSE and optimizations I mentioned I increased the speed of the original(already profiled and optimized) code by 4x. Right now I'm almost at real-time raytracing speeds. By using CUDA or something similar I can easily achieve realtime raytracing. That means raytracing game engines are just around the corner. Those kind of technologies will never happen by using C#. (Well, not never, just much much later)

    Without using SSE, you are never getting maximum performance out of your CPU.

    Sure, usability is very relevant, and when working with Unity I'll always prefer C# because there are simply not that many performance critical operations. All of the performance critical ones are being done in the internal C++ part of the engine.

    My point is, if you want games as pretty as crysis, uncharted, etc, you have to use C++(or even other low-level language) to develop your engine. You have to sacrifice usability, readability, maintainability, to get that much performance out of an engine.
     
  25. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    Again, why? It's stupid to make hardware that doesn't provide for fast results in the easiest way possible. I don't know anything about hardware design. Is it just impossible to make a great programming language, and have it interact with hardware faster than anything else?
     
  26. BearishSun

    BearishSun

    Joined:
    Dec 1, 2008
    Posts:
    175
    Yeah that would be the easy solution, but todays CPUs and compilers are doing just that. They rely on branch prediction, temporal and spatial locality, trying to predict exactly what are we going to need and use, and compilers try to optimize our code to use those features as best as possible.

    But still no machine is smarter than us, and cannot predict exactly what we want. If we know what we want, we know the best way to use the machine. For example, while compiler automatically used SSE on some of my original raytracing code, in order to get actual 4x improvement, I had to completely rewrite and redesign the tracer kernel. Entire higher-level organization of the tracer was changed in order to accommodate SSE. Compilers are still a long while from being that smart.
     
  27. zibba

    zibba

    Joined:
    Mar 13, 2009
    Posts:
    165
    SSE is the Intel Pentium vector processor extension. I think it stands for Streaming SIMD Extension. They started out being known as MMX back in the day. The PowerPC equivalent was AltiVec. On the iPhone it's VFP and NEON. Why do you need this? Well in 3D games they're most often used to optimise matrix multiplication. So rather than writing a typical matrix multiplier in C++ or C#, in which the algorithm and code is all pretty much the same, you'd write the body of the function with inlined assembler using SSE instructions. This gives you a significant speed increase (I forget how much). Why? Because C++ compilers don't automatically generate SSE (*some have macros that you can use). With C# you don't have that option. You have to use an unmanaged call out to C++. The .Net JIT compiler, AFAIK, also doesn't generate SSE, so you're simply unable to get the maximum out of the hardware.

    You're point about it being possible to make a language to do this, yes I think someone did make a C compiler that is vector processor optimised, I don't remember who, but they're not common. Historically Fortran has also been used for this. The languages, C/C++ and C#, and their optimising compilers don't provide the functionality to use vector processing automagically. Therefore, to get the best out the hardware, C/C++ is your weapon of choice.

    In Unity's case, one hopes that their matrix vector classes have been appropriately optimised.
     
  28. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    C++ does not automatically optimize for SSE either. There was a thread on game dev about this a while back. The C# .net JIT compiler does optimize for SSE in some cases.
    http://www.gamedev.net/community/forums/topic.asp?topic_id=504224

    XNA has vector and matrix classes as does slimDX. I am not sure exactly what the windows API code pack gives you. However, it should be similar. Are you really going to write your own math library? If you where then I would use C++.

    As for raytracing that sounds like a job for the GPU anyway.
     
  29. zibba

    zibba

    Joined:
    Mar 13, 2009
    Posts:
    165
    The problem is how do you vectorize from CIL code? In Mono and .NET the obvious place is type conversion. Anything else would be very tricky for the JIT to figure out. So you run into the costly managed/unmanaged boundary. Much better to use C++ and SSE intrinsics. I don't know about XNA, but I haven't seen any SSE in SlimDX.

    GPU raytracing bring out the CUDA.
     
  30. aaronsullivan

    aaronsullivan

    Joined:
    Nov 10, 2005
    Posts:
    986
    Big Picture:

    Hardware doesn't work like we think. It's that simple. People who learn exactly how the hardware thinks and can tell it exactly what to do will be able to get more efficiency out of the machine. The higher level languages are at their heart doing generalized optimizations with limited information.

    C/C++ gives you hooks into the workings of the hardware (through asm and other methods) C# and other JIT languages generally do not.

    How does this effect Unity users? It really doesn't. The underlying engine is using what it needs to and they are doing the close-to-the-metal work for us. :D
     
  31. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    as zibba said

    I agree and thus this does effect unity whether you want to admit that or not.

    Plus unity uses mono with is not as optimized as .net

    Still I am not sure that SSE is as vital as some are making it out to be. MMX was not even used for the longest time.
     
  32. aaronsullivan

    aaronsullivan

    Joined:
    Nov 10, 2005
    Posts:
    986
    But who is looking to vectorize in Unity scripts and for what optimization? My point is that for the majority of projects the optimizations are going to take place in the underlying engine and UT has full control over this in its C++ code base of Unity.

    If you want to talk about competing with other AAA engines there are much bigger disadvantages to using a generalized multipurpose engine such as Unity than what little comes from managed code that the scripts are running with.

    Most people are here because they are intentionally sidestepping the building of a specialized engine due to cost/time and are interested in applying their own talents such as game design, general creativity, or proficiency in creating assets. They just want to take it that extra step to make a fully functioning game in a quicker time.

    So, do these issues effect Unity users? I maintain that they really don't.

    I'll concede it does matter to a few, but they are well-served by the C/C++ plugin architecture in Pro, for occasions when it is needed.
     
  33. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    ... which, IMHO, gets more and more important as hardware gets more and more diverse. If you code in C++ your code gets compiled - and that's it. You can just use what you know; and if some new technology comes around, you're out of luck (well, you have to recompile, or - more likely - change the code, very likely introducing additional code-paths for different environments; with additional potential for bugs that are more difficult to track down).

    With managed languages, on the other hand, the JIT-compiler (or the implementation of the APIs) can use whatever is available on the machine you're currently playing on. SSE, for example, is supported by Mono (see this discussion).

    Of course - someone's got to do the work and someone has to have the knowledge; and if you rely on the people that code the JIT-compiler (or API implementations) ... or on Unity which only updates Mono every few years ... that could be a problem. Also, there sure are some cases where super-optimized hand-coded assembly code rules - but in the context of Unity, there's no reason why such things should not be implemented in the engine and be accessible through a convenient API (except that the Unity devs either don't see the need for such super-optimized stuff; or don't have the time to implement it which means it doesn't have enough priority ... and that puts up the question: is it *really* needed then? ;-) ).

    I guess in the end it really comes down to: Do you want to code everything from scratch to gain those last few percent of performance? Or do you want to create games that are fun? I think both at the same time is only possible if you have a huge team and lots and lots of money to spend. Personally, just like I don't care for the best currently available hardware (which usually costs twice as much for giving you around 5-10% more performance), I also don't care for those last few percent of performance I could squeeze out if I did everything myself (which would probably cost me thousands of times as much as using Unity costs me).

    On the other hand: If someone really finds joy in super-optimizing for every kind of processor out there ... right on! As long as it's fun, it's the right thing to do ;-)
     
  34. bpatters

    bpatters

    Joined:
    Oct 5, 2009
    Posts:
    164

    Managed Languages like C# and Java are definitely the future for applications and many could argue the present and not future. However for the underlying engine that is used for the games and applications C++ will be around for a long time still. On mobile devices C++ even has a bigger role because of the low power, memory, and performance sensitivity.

    Personally I'm more interested in creating content than engines, which is why I like Unity and C#. However C++ does have it's place and won't be supplanted by C# anytime soon.
     
  35. aaronsullivan

    aaronsullivan

    Joined:
    Nov 10, 2005
    Posts:
    986
    I still like talking about progress on languages and the engine side of things. :D

    There are times that I like digging into that side of things. I've never gone into deep optimizations or a modern engine at all but I have a "from scratch" engine for my iPhone game -- Hey, it _was_ going to be done before Unity iPhone even released until certain life events interrupted. I've done previous smaller games in C++/OpenGL as well.

    All I've been saying is that the managed code issue is not directly relevant to developers using Unity as their engine. Of course, some knowledge on the issues will be good to have when Unity introduces updates to the underlying engine. Will be nice to compare what direction UT goes in compared to other engines, for instance.
     
  36. Deleted User

    Deleted User

    Guest

    Wow, this topic is still active :D
     
  37. Vimalakirti

    Vimalakirti

    Joined:
    Oct 12, 2009
    Posts:
    755
    It's a religious issue.
     
  38. AmazingRuss

    AmazingRuss

    Joined:
    May 25, 2008
    Posts:
    933
    Exactly. I spent almost 2 years trying to knit a cross platform engine together out of OpenGL, Ogre, OpenAL, Lua and a yet to be named physics system. It was extremely fun working on all that, and it would have been the Best Game Engine Evar, but I had no game, and no income.

    I stumbled on Unity while trying to figure out how to get my linux-born engine to compile in xcode. At that point, every time I would try to build, it would crash my mac nearly instantaneously... like somebody frakkin' power cycled it! It just cut the mighty OSX off at the knees.

    I had been fighting the problem for several days, and was reduced to a quivering mound of frustated, mind-numbed human jello, feebly googling for solutions with an ad-hoc extruded appendage, trying them, and watching my mac crash and reboot, when Unity came up on the googles. I was just desperate enough to go for the 30 day trial.

    It was a moment of religious conversion for me. When I remember it, there is a bright beam of golden light, and a choir of cherubs singing.
     
  39. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Yeeha - and thus, another Unitoid was born. Unity FTW!!!

    8)
     
  40. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    Wait you do realize he's talking about adding intrinsics to mono don't you? Which would give you direct access to SSE.
     
  41. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    That's true. In that case, Mono wouldn't be auto-doing the dirty work for you - but at least it would allow you do it yourself.
     
  42. MadMax

    MadMax

    Joined:
    Aug 5, 2009
    Posts:
    203
    You still have the managed/unmanaged boundary with plugins. Also when every you use the API you're making a costly unmanaged call.

    Do not get me wrong I think it is worth it sometimes.
     
  43. mar10

    mar10

    Joined:
    Jan 30, 2014
    Posts:
    11
    C++ is used to create optimized fast code but development time with it compared to script languages is much longer unless you are part of a big team, engines that need to be developed in c++ is the way to go but if you are part a small team or by yourself; script languages are the more practical path to completing a project unless time is not a factor in development. script languages were designed to supplement the more labor some languages like c++ to cut down development time. I was developing in c++ & then switched to unity because with its script languages it is more feasible for a guy like me to finish developing a game by my self or with a small team. this is why I think based on personal experience unity is the more favorable choice for a single or small development teams. the engines are already developed in c++ which took several years with large teams working on it & continue to do so as time passes by so why build on top of that with c++ just use the scripting to extend what the engine can do & get a game out quickly.
     
    Last edited: Mar 25, 2017
  44. mar10

    mar10

    Joined:
    Jan 30, 2014
    Posts:
    11
    c++ is a standardized language & is the language used to build complex software mac & windows OS is built with it & so is facebook's backend converted from PHP, cryengine, unreal & unity are built with it as well, large software that is impossible to build & optimize with script code. C++ has been designed with strict coding in mind it a superset of C which is a superset of cobol one of the earliest of programming languages. c++ has been built to be faster & easier to maintain, that is why it is what is used for large projects with large teams even the interpreters for the script languages are built with it. script languages are the ones prone to bad coding & require more discipline & enforcement of coding standards because it is only meant to extend the main software's features & functionality.
     
  45. mar10

    mar10

    Joined:
    Jan 30, 2014
    Posts:
    11
    computer science is the science of computing which is the foundation for software engineering.
     
  46. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Nice necro.

    Anyway the current answer is C# is currently the best (most productive) language to make games with. Globally more games are made with C# then any other language.
     
    Martin_H likes this.
  47. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    You're baitin' flame with a post like that! :p

    Many many game developers do their day-to-day work in C#, yes, but the games made with C# are in many cases also made with C++. Different bits of the game are made in different languages, depending on what suits each bit best

    And that's what it boils down to - using the right tool for the job. The "low level" stuff that needs to be really fast can take great advantage of the things that languages like C++ have to offer, such as (relatively) direct control over memory. The "high level" stuff like the rules for a game's mechanics can take great advantages of the things that languages like C# have to offer, such as the improved productivity of letting the compiler and runtime deal with a whole bunch of details so you don't have to.

    Asking what language is better is like asking what kind of hammer is better: it depends entirely on the job at hand.
     
    Kiwasi and Martin_H like this.