General > General Technical Chat
How many people code in C these days, and if so, why?
Kosmic:
--- Quote from: Berni on May 07, 2020, 04:16:31 pm ---Yes i know there are differences between a machine code DLL and a CLR DLL. But UE4 will handle it with a simple plugin.
--- End quote ---
Well it's not because you can hack a CLR inside UE4 via their plugin system that's it's a good idea. It's clearly not officially supported. To go back the game you were talking about, Fortnight , I can guarantee that you will find 0 line of C# in there.
--- Quote from: Berni on May 07, 2020, 04:16:31 pm ---And yes C# is indeed not interpreted directly like Python. Its crunched into the .Net IL and this is then JIT compiled to platform specific machine code on the fly. This is the reason why C# is actually really fast, it only needs to be compiled once, then the code is essentially machine code. Sure it might not be the C level of performance, but its not that far behind. Hence why it does end up used in games so often. Most of the complex gameplay related game code is not being executed all the time so it does not matter if the code runs half as fast as it could in C++, it won't run often enough to visibly degrade performance, yet the creature comforts of the C# language make its development and troubleshooting significantly faster (this game logic is often a lot more complex in terms of many more variations in behavior, more variables etc). Games are huge and have long load times so recompiling a game for each test run is not desirable. For this reason a lot of games in the last 30 years have some sort of non precompiled language inside it(Lua used to be popular for this), it makes game development easier, since the non programmer person plonking down game NPCs can just quickly edit a file in notepad while the game is running. The only difference with C# is that its the first such popular language that is performant enough to be used for a lot more than just simple NPC behavior scripts that run once every few seconds. Go have a look at some C++ vs C# benchmarks and see how close to C++ performance it actually is.
--- End quote ---
I'm well aware of the difference between C++ and C# and even if C# is better than Python, it's a lot worst than C++. Also, speed is not the only problem with C#, memory management and the garbage collector is a huge pain. Almost impossible to solve. Integrating scripting language in professional game engine was done mostly between 2000 and 2010. Like I said before, these days visual scripting is a lot more popular and is normally powered by C++ like the rest of the code.
--- Quote from: Berni on May 07, 2020, 04:16:31 pm ---I have looked at my Steam install directory and out of the 40 games installed 19 of those games had a folder named "mono" full of windows mono dll files. So it is safe to say a significant part of games make use of of it. Tho by now core.Net is replacing mono by doing the same job.
--- End quote ---
Small indie games made with Unity or with some other small game engine ship on PC with mono yes. Never the case for AAA games.
--- Quote from: Berni on May 07, 2020, 04:16:31 pm ---My point is that non C++ languages are used a lot in game development because they have advantages that outweigh the performance cost. They are still not a replacement for C++. But for the usual one man band engineer writing software to run on a PC with GUI the whole C++ thing is usually not a good fit. The slight performance gain is not justified by the extra time, effort and expertise required. If raw performance was the main metric then everyone would still be doing assembler.
--- End quote ---
I don't have a lot of visibility on the indie/small game scene, but on the AAA space those languages are not used anymore for multiple years now. Everybody moved to visual scripting and the rest of the engine and code is C++.
Small developers working on small games do what they can and it doesn't mean it's a good idea. For exemple, integrating C# in UE4 for me is an aberration. You should use the engine the way it was designed and put your logic in the visual scripting language (blueprint) and not C#.
Kosmic:
Another bit of information, C# performance are so dreadful that Unity started working on their own compiler (called Burst) where they compile C# code directly to platform assembly code, skipping the CLR entirely. Only problem is to do so, they had to cut the 3/4 of the language features :-DD
like IL2CPP, their own custom C# compiler is probably not a good idea. Personally I think that for games, C# should be avoided.
engrguy42:
Why is there always a battle to prove who's "right", when there's no "right" answer??
All languages have pros and cons. There is no perfect language. Coming up with these somewhat irrelevant pseudo facts doesn't prove anything. Yeah, some users somewhere might not like a feature/characteristic, but others elsewhere couldn't care less.
There's always this ridiculous battle to prove who's right.
Just accept it guys. All languages have pros and cons. Just because YOU might not like some aspect of a language doesn't make that relevant to the rest of the world.
BTW, replace the word "language" in what I just posted with any technical thing: meters, scopes, power supplies, etc., and you've pretty much defined many of the discussions here
Kosmic:
Not a matter of right or wrong, I'm stating some facts and communicating my humble opinion.
It's probably not clear but I love working in C#. It's the language I use for my personal projects. It's just not a good idea to use it for everything.
SiliconWizard:
--- Quote from: Berni on May 07, 2020, 04:16:31 pm ---If raw performance was the main metric then everyone would still be doing assembler.
--- End quote ---
I always find this kind of reasoning a bit exxagerated - there's a whole world between an high-level, running on a VM language, and assembly.
Raw performance may or may not be your main metric depending on the project, but even if it's not, you still have a handful of reasonable solutions to choose from.
And that said, for the fun fact, some people are still writing complex stuff in assembly: http://menuetos.net/
Not saying this makes a lot of sense, but it's fun.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version