[=;16236]
When i first used c++ i felt free like a bird.
[/]
This. C++ made me feel empowered to tackle anything (within my far more limited scope than a AAA big name coder for sure but nonetheless).
[]
When i first used c++ i felt free like a bird.
[/]
Couldnât agree more.
c++ vs .net managed (c# etc etc)
.net is created by Microsoft, and they are not well known for making things cross-platform. This results in your code being Windows only without the possibility of converting it to cross platform if you wish to do so. So that rules out mac and Linux for example.
C++ is used by most platforms, this means you can make your code cross platform without to much work, of course there are api functions that are platform specific but its much easier adding a couple of #if statements then re-writing the whole of your code into a different language.
Your .net application gets processed via a middle man (the best way I can describe it with out going to technical)
c++ gets compiled to assembly - the closest readable language before it gets processed.
This results in a speed difference, dependant on the software depends on how much.
Im trying my hardest to write this without making it an Anti-Microsoft tant so im going to keep it short.
.Net is way to reversible.
.Net is slower
.Net is not multi-platform friendly
.Net is bloated
a down side to c++?
Its not as easy to learn compared to the .net languages.
just my opinions 
cheers
Greetings MinionPhil. Check out Mono C# which is multi-platform
Some guys are also trying to integrate Mono into Unreal. See this thread.
Hi ,
Yea Iv seen mono before, I seen it years ago for running asp.net websites on a Linux server.
To be honest iv never actually tested mono to see how it performs.
So with that, This could be a unity issue, mono issue, or just the game developers issue.
For background reasons, I am a local memory hacker, tho the reason I am here on UE is im teaching myself how to develop games not for hacking purposes.
The game im going to talk about is the only game I know that is MP only and uses the unity engine.
This game has one big problem when it comes to hackers, what we do is simply edit the .net dllâs to manipulate the game, no hooking, no debugging, no working out functions in assembly, it also meant that we could reverse the source to pretty much 100% usable source - this resulted in the end user being able to change things like the user id to stop them being able to be banned. Un-Ban able hackers? its destroying this game.
Performance:
The network for this game because everything is wrapped in .net has made its network performance slow, its made a simple network communication jump all over the place before actually being sent - when I debugged the game - it literally jumped via the .net framework and then to Winsock without the data actually being modified.
But like I said this could have 3 points to blame, it could be any - Only real way to find out is to have the source
Im not dead set against the .net languages, I just have a big problem with it for games. For standard windows applications it has got nice widget libraryâs that make it very simple to create native styled applications as well as custom styled application.
If UE was to go .net I Personally think they are going to open more doors people want to shut then doors people want open.
[=MinionPhil;16714]
.Net is way to reversible.
[/]
This is very true, managed code languages are ridiculously easy to decompile compared to native binaries.
[]
.Net is slower
[/]
This however is not. In-fact, Java and C# is often as fast as, or faster in real-world applications. jvm/clrâs self-optimizers are amazing, you rarely see C/C++ in web services for this reason, once the self-optimization reaches its peak, jvm/clr starts beating C by a pretty wide margin. Câs strength for an engine isnât necessarily its speed, itâs its consistency. Managed code platforms trade consistency for raw speed(functions get faster the more often theyâre called, but the first time and the first few thousand times theyâre significantly slower). So for a game engine theyâre a poor choice for the rendering pipeline, but a valid choice for game logic.
[]
.Net is not multi-platform friendly
[/]
True to an extent, Mono alleviates some of this, but Mono has its own licensing issues, until thereâs a truly free and open source equivalent of .net I wouldnât use it personally.
Ultimately I support as many language choices for UE4 as the community wants to support, Iâd rather program game logic in LISP or Clojure personally, and I like that I have the freedom to write plugins to do so.
Yeah on this one title I shipped we were using an in-house scripting language that compiled down to byte code. It was pretty bad. Our designers couldnât debug and it was kind of unfinished, since no one wanted to spend time making it âproâ.
To get to the point, being the C# lover I am, I suggested replacing that monster with C#. At least then our technical designers could debug. But no one wanted to bother with looking into Mono licensing for /Xbox360 platforms. Plus we knew our boss wouldnât go for it anyways, since he was the one that wrote the scripting language anyways
Eventually, we started looking into the WiiU and noticed our scripts were too slow. Not sure how detailed I can describe this on a forum but surely knows the specs for it these days? Anyways, it was looking like we were going to have to toss our designers at C++. A few of them had programming degrees. Theyâve just never used them
I ended up leaving that for another opportunity but since then theyâve ripped out the scripts due to switching engines and the Designers are programming in C++.
So if these guys can do it I know you guys can!
[=;16252]
This isnât to say that C++ is the ideal language for simple gameplay code. It is more complex and more dangerous than UnrealScript, C#, and JavaScript. But that is another way of saying that itâs more powerful.
By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish, whether it involves debugging your entire codebase in-context, interfacing to low-level engine systems, modifying them, or talking to the operating system or advanced third-party libraries.
[/]
Dear & any Epic Devs reading this thread,
I have created a thread thanking you for the awesomeness that is UE4 C++!
Thank you for sharing your Heart with the World!
I hope you know how many of us are ever so grateful to you for giving us this opportunity!
https://.com/watch?v=Sh19_Py5ff4
PS: There is an easy resolution to this thread
Infinite Power = C++
Consider being grateful that you are being offered such power for such a small fee, with such an incredible code base to work with!
I am excited that there are some community projects to introduce support for other langauges, but I really think Epic deserves more thanks and appreciation for what they have offered all of us.
Personally, I find C++ to be very⌠likeable. Itâs fast, itâs powerful, and it makes life miserable for people who just donât know how to code, which can really help lower the number of crappy games we see on the market these days, or at least keep them from having a âPowered by Unrealâ logo attached, which would just be awful.
However, there are a few downsides as well. One is the super-slow performance of Intellisense. It struggles and almost always fails to keep up with me when I code. Second is the fact that with C++, an error means instant termination of the entire engine. I was kinda getting used to the error logs in UDK and Unity, and it just hurts to see the entire editor crash because of as simple a bug as a null pointer being dereferenced. There is also the fact that, at least on windows and with MSâs implementation, C# tends to do a well enough job of keeping up with the speed of ânativeâ programs using JIT compiling, so it can be fast enough for games, but never safe enough.
All in all, for all the various reasons mentioned by others, the decision to move to C++ is definitely a good decision in my eyes. After all, C++ is the language upon which almost everything is built.
Why are so many ppl hating on c++? When you have an existing library like UE4 to work with c++ is as easy as c#, its not like you are going to be needing the complex c++ features to build from scratch anyway.
[=Arshia001;16837]
However, there are a few downsides as well. One is the super-slow performance of Intellisense.
[/]
This is Visualâs problem not C++. Visual is written in C# and C# cannot cope. Intellisense lag in Visual 2010 and onward has nothing to do with C++. Try Visual 2008 which is written in C++ and youâll see no intellisense lag at all.
[=VFe;16784]
This is very true, managed code languages are ridiculously easy to decompile compared to native binaries.
In-fact, Java and C# is often as fast as, or faster in real-world applications. jvm/clrâs self-optimizers are amazing, you rarely see C/C++ in web services for this reason, once the self-optimization reaches its peak, jvm/clr starts beating C by a pretty wide margin.
[/]
This is not a fact. This is fairy tale and you should really get your facts straight.
Best way is to provide some evidence to what youâre saying.
[=cman;16872]
Why are so many ppl hating on c++? When you have an existing library like UE4 to work with c++ is as easy as c#, its not like you are going to be needing the complex c++ features to build from scratch anyway.
[/]
You are absolutely right.
[=;16828]
Infinite Power = C++
[/]
Iâm not sure if thatâs your intention, are you sure you didnât mean
Infinite Power == C++
Just trying to be lighthearted so please donât shoot me 
,
thanks for explaining. But let me tell what Iâm thinking about it.
With the recent price change for UE4 itâs clear that Epic is now aiming @ indies and not at AAAs only. Those small devs (itâs me, ha!) are very used to the simplicity of Unity and easy [scripting] languages. So, itâs great that UE4 enables us to do everything with the power of C++. BUT⌠For the new devs, itâs simply too much. On the other side, blueprints are cool, but not as power enough to create an entire game.
My proposal: please provide a lot more tutorials and documentation. Especially for âswitchersâ. Thereâs still a very steep learning curve ahead.
Thanks!
These debates are bound to happen and they get emotional because the choice of language is often based on âwhat you are comfortable withâ. I can tell a lot of people here are coming from a Unity background and appreciate its accessibility from C# through the documentation etc. My background: 15 years in professional game development as an engine programmer, Iâve used C++, C#, Java, extensively.
First off all, I think there is a misconception and people are latching too much onto C++. Epic has a far more elegant solution to scripting: Blueprints. Anyone who is comparing Unity C# to UE4âs C++ has missed the entire boat. Unity is also written in C++, they just donât give you the source code. Any criticism leveled at UE4 because of C++ is equally applicable to Unity.
Secondly, who is coming from Unity and is used to C# should be looking at Blueprints not at the C++ engine source. UE4âs C++ source code is not for people who are used to scripting GameObjects and MonoBehaviours in C# in Unity.
And the final much more heated debate are the merits of C# vs C++.
Letâs start with the âlanguageâ part of C# vs C++ and ignore the performance aspects of the situation first:
As a language, C# and all languages built around the IL specifications are inferior to C++ because they lack several major features: compile time const-ness, a true Turing complete template meta programming solution, pre-processor macros that support substitution and reduction, the ability to do full static analysis, and multiple inheritance.
For the beginning programmer what does this all really mean? Letâs take a good example with const: multi-threading. In C++, because of const, it is much easier for me to produce a set of classes or an API that effectively communicates threading semantics between two classes that is enforced at compile time. If I have two systems A and B and they need to share an object, (where A can modify and B should only read) then it can simply be done by passing a âconstâ (cannot modify) version of that object to B. B can no longer ever call a method on the object that will modify its contents. This is enforced at compile time: if you tried to modify it it would fail with an error when compiling. That alone eliminates an entire class of thread synchronization bugs.
There are equally powerful cases for all of the other C++ language features. They range from convenience, to extraordinarily important if you want to be able to do something truly the right way.
C# has some superior language features as well but they donât tip the scale in its favor:
C# has anonymous functions and closures: This is incredibly powerful. C++ added this in C++ 11 and it is arguable more powerful there but there is an elegance that C# has because it is GCâed that C++ does not. If I truly had a wish though C# would have first class methods like Lua.
C# has (at least on windows) has windows forms. Not a language feature but itâs nice for tools.
C# has reflection, which is awesome. UE4 also has a reflection system as well, but itâs not a language feature of C++.
**Now letâs discuss performance in C++ vs C#. This is arguable more important than the language features (at least from some perspectives). **
I will begin with some follow up information if anyone really wants to get into this: http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
The bottom line on this point is that C# is slower than C++. And if you use mono to compile your C# (like Unity does) then it is significantly slower. Using the microsoft class of IL compilers C# at its peak can almost match the speed of C++, but those are during its best cases. Generally C++ outperforms C# by a significant margin.
The types of optimizations that C++ goes through are more advanced and more significant than what are possible with C#. For example, did you guys know that every time you index an array in C# there is a bounds check in the array? Also C# has its own set of issues and concerns, specifically with mono: Almost all Generic.Collection<> classes in the C# runtime return structs from their IEnumerator interface (as they should). However, mono does not compile this correctly: and it converts structs to object types on the heap causing boxing/unboxing overhead on each iteration. Bottom line: foreach() is slow in Unity so it canât be used as efficient alternative to avoiding the overhead of indexing in C#.
C# also makes it impossible to modify a value type without indexing because it lacks reference-to-value-types. Example:
void DoSomethingWithArray(MyStruct] arrayofvalues)
for (int i = 0; i < arrayofvalues.Count; ++i) {
if (arrayofvalues*.shouldBeModified) {
arrayofvalues*.modifyValue = calculateNewValue();
}
}
The above requires two indexes into arrayofvalues, requires two out of bounds checks. Can this be optimized out? No it canât, the compiler has no guarantee that arrrayofvalues wonât be modified on another thread during the if() and the assignment inside the if.
People say C# bad because it is garbage collected, but isnât UE4 also garbage collected?
This is a blessing and curse for C# and all GCed languages. Generally speaking GC (managed languages) are a net positive for the programmer.
The reasons arenât always really what people think: yes in C# you donât have to explicitly free memory, but that not the biggest win. The big win is that when Iâm writting 50,000 lines of C# I donât have to arbitrate what system is responsible for any given allocation. Because I donât have to do that for literally thousands of places where an allocation occurs you eliminate a massiave swath of common mistakes: freeing a memory multiple times, overwritting freeâd memory, overwritten memory you thought was yours but was freeâd and then reallocated and given out to someone else. There are lots of expressions of these types of errors that can happen in a large project. They all lead to terrible issues: one of your objects gets overwritten by random garbage, you get a crash when you try to allocate or free memory because someone overwrote memory and stomped on the internal C++ heap house keeping structures. All kinds of nastiness.
GC is probably the best thing C# really has going for it. BUT itâs not all roses either: letâs not gloss over some realities that all managed (Unity) programmers have dealt with as well: Memory leaks. In C# you either get nullrefexceptions or you leak memory. Because its a managed language, a programming mistake can often lead to leaks instead of crashing. Both behaviors are arguably wrong. And C++ doesnât really have clear win.
However, if you make a mistake the behavior in both cases (managed/unmanaged) it is still incorrect, just differently bad.
Why C#'s garbage collection is bad, and why UE4âs GC is better.
Both C# and UE4âs UObject and blueprints and gamecode generally are all GCâed as well. So why did Epic do this? Because there is one major pitfall with C#'s GC: performance and predictability. Anyone who has done anything of complexity in Unity knows the bane of the GC hitches. Youâre crusing along just fine and then BAM, a 500 ms pause hits you. Or the lovely continous stutter step every 2-3 seconds.
These are garbage collection spikes and there is no way to control when they happen or for how often, in other words there is no predictability.
UE4 is garbage collected but the way their object system is reclaimed and disposed is designed to be predictable and have a flat performance profile. C#'s GC is designed to work for spreadsheet applications and database front ends. Itâs a general purpose GC. Itâs not designed from the ground up to be a GC for a real-time application where a flat performance profile is the most important requirement.
Adding C# to UE4 is redundant and not a good idea
So for the above reasons C# is not a wise addition to UE4, UE4 already has a scripting system: Blueprints. Use blueprints for everything you want to do with C#. Use C++ to extend and modify UE4 in any way you want to. You canât extend or modify Unity at all, unless you want to fork over the cost of a source license. And Epic has made it clear from their Twitch broadcasts that they are working towards an integrated system with to provide instant access to checkins on the main source branch as they happen.
Epic actively wants the community to dig into the engine and extend and improve it. Thatâs why theyâve given us the C++ source code.
Aside from Blueprints, GC, and C++ UE4 is superior to Unity in every other way
Point for point, system by system, Unity is not competitive with UE4 (except it exceeds in documentation). Not even the slated features of Unity 5 matches UE4, it only narrows the gap a little bit.
There are major systems in UE4 that Unity totally lacks, and they are not trivial things, they are systems that it takes expertise in to replicate. They could be done in Unity of course, and the Unity community has provided addons to fill in some of the short comings, but they arenât done in an integrated system like in UE4. Hereâs some of those missing things that UE4 has but are lacking an integrated solution in Unity:
- A real networking solution with client side prediction and authoritative network architecture.
- Built in platform agnostic online subsystems and match making with support for Steam, Game Center etc.
- Behavioral trees and AI systems: Unity has no system for you to create and produce AI or NPC login. You have to start at the lowest level and write your own code to move objects around. Then pathfinding etc.
- Unityâs mechanim system is not as robust or sophisticated as UE4âs.
- Unity has no material node graph. Unityâs renderer (even Unity 5âs) is inferior.
- Unityâs built in GUI is terrible, but there are replacements like NGUI and Diakon Forge. UE4 is about to get Coherent UI and Iâm sure the community will fill this void unless Epic gets to it first.
Thereâs more than this but itâs just an example of the really hard stuff you still have to implement yourself in Unity or buy piecemeal solutions for on the Asset store. And the asset store solutions arenât always the quality needed to actually ship something.
TL;DR
- If you are upset that UE4 uses C++ you are missing the bigger picture: UE4âs Blueprints are the equivalent to Unityâs C#, but blueprints are superior.
- C# is slower than C++ in almost all cases, and much slower when compiled with mono which Unity uses.
- UE4âs method of garbage collection is better than C#'s generic GC.
- UE4 is superior to Unity. Itâs not merely an equal or an alternative.
[=cocoapriest;17006]
,
On the other side, blueprints are cool, but not as power enough to create an entire game.
Thanks!
[/]
That is patently false. Blueprints are capable of doing a complete game, you just need to learn more about them. Watch this video, itâs a full hour of someone explaining their entire game is done in blueprints:
https://.com/watch?v=JFZCp4xsPmo
[=;17086]
Blueprints are capable of doing a complete game, you just need to learn more about them.
[/]
I agree with !
Having played with both BP and C++ quite extensively,
I am actually quite sure that** the limits of BP are currently unknown**, and they are an amazingly powerful tool you should dive deeply into and see how powerful they are!
[=;16980]
Iâm not sure if thatâs your intention, are you sure you didnât mean
Infinite Power == C++
Just trying to be lighthearted
[/]
Hee hee!!!
Great to hear from you !
**UE4 C++ Update**
Thanks to UE4 C++ I can now generate complex shapes at runtime, **UV map them**, and then give them collision!
Check out one of my player characters **standing inside** a complex uv-mapped shape!
I just now generated this shape and took the picture, in-game the whole time, editor was never opened!
https://www.mediafire.com/convkey/e081/27c39zzh11o41z06g.jpg
:)[=;17083]
âŚ
Secondly, who is coming from Unity and is used to C# should be looking at Blueprints not at the C++ engine source. UE4âs C++ source code is not for people who are used to scripting GameObjects and MonoBehaviours in C# in Unity.
âŚ
[/]
This is where you missed the mark. C# programmers should not be looking for blueprint nor the source code (provided through ). The Equivalent of Unityâs C# in this case is the C++ API provided with the engine (not talking about performance or anything like that here). The amount of features that both engines provide are huge, Unity is more straight forward (simple) and Unreal Engine 4 is a little weird a first but has insane amount of out of the box features. Like some said, the amount of stuff in UE4 library makes this as easy as C#. Makes absolutely no sense to compare a high-level and powerful language like C# (and C++) with blueprints.
Personally I prefer C++, but Iâm still learning UE4 since itâs a little different from what Iâve done and used in the past (thereâs no way that I will port from Unity to Unreal without knowing it first). People that created a engine before (from scratch) probably created something that looks similar to Unity (entities, game objects, raycast, âŚ), thatâs why UE4 looks very alien to some (pawns, traces, overall syntax, âŚ).
[=;17108]
Thanks to UE4 C++ I can now generate complex shapes at runtime, UV map them, and then give them collision!
[/]
And itâs so promising! For example, now we can implement dynamic slicing as it was done in Metal Gear Solid. Or ingame terramorphing⌠so many opportunities!