Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why C++ for Unreal 4

forums.unrealengine.com

Post reply on HN
Print view View original

51–60 of 178 posts

Re: Why C++ for Unreal 4

#51

Post by Pxtl »

berkut wrote: post #24
pjmlp wrote: post #20

The whole C# vs C++ discussion going on the forum shows how little current generations understand of compiler design and language implementations, oh well...

Exactly. What's most distressing is people (as normal) are completely ignoring the garbage collection overhead, which is mostly where the advantage of having complete control is, in terms of micro-managing your memory allocation, e.g. using slab allocators, memory pools, pre-allocation, etc. C# code in theory (ignoring things like intrinsics support and inline asm) can be as fast as C++ for tight loops, but in my exp…

C# has support for stack-allocated "struct" objects that avoid the GC. They have their limitations and gotchas, being somewhere between simple C structs and C# classes, but they exist.

GC-based languages run games on many, many platforms. The problem, imho, is that you have to leave 90% of the language features on the shelf when you're doing your main loops in order to avoid triggering the GC.

The gaming industry is practically begging for a language like Rust.

Re: Why C++ for Unreal 4

#52

Post by pjmlp »

simias wrote: post #42
octo_t wrote: post #2

The phrase > 'What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.' is beautiful and is a pattern I've seen multiple times before. Its not feature creep per-se, but more something a bit more insidious in software development.

That's a good lessons for people wanting to create a new languages too. One of the reasons C++ was successful in the first place is that it needs almost no glue to interface with C code. Contrast that with all the languages providing a more or less cumbersome FFI. Rust for instance looks very promising but you still have to go through the tedious task of redeclaring all the prototypes of the C functions before you ca…

Another one is that all successful system programming languages have a OS vendor shipping them on their OS SDK.

That is the only way to make people adopt them. Otherwise they become just another language to do business applications.

Re: Why C++ for Unreal 4

#53

Post by k00pa »

archagon wrote: post #5

On the other hand, I feel that tools like Unity are successful precisely because they let you tinker with your game in a WYSIWYG kind of way. It's really liberating to be able to work inside such a tight feedback loop, and it's a little weird to see a modern game engine distancing itself from that approach. (But maybe I'm missing something. What exactly is the role of the Unreal Editor in UE4? Is it mostly for things…

You can use the blueprints to create the game, you can also use the C++ to create the game.

You can also mix up the blueprints and C++.

At this point Unity only really has simplicity because of the lack of features, and well if people are too scared about C++.

Re: Why C++ for Unreal 4

#54

Post by pjmlp »

m_mueller wrote: post #44
pjmlp wrote: post #25

Earlier quoted context omitted.

Note that Unreal uses a C++ GC.

I'm neither an Unreal nor a C++ expert, but I assume that this kind of GC still allows exact control over when the collection happens since it's not language- but a library feature. In this case this should still be better for game engine purposes, since the GC can for example be hidden behind GPU rendering time.

C++ has a GC API since C++11.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267...

Currently Visual C++ is the only C++ compiler offering support for it.

As for Unreal, I only know it has one by reading game development foruns. I don't know what type of control it offers.

Re: Why C++ for Unreal 4

#55

Post by pjmlp »

Pxtl wrote: post #51
berkut wrote: post #24

Earlier quoted context omitted.

Exactly. What's most distressing is people (as normal) are completely ignoring the garbage collection overhead, which is mostly where the advantage of having complete control is, in terms of micro-managing your memory allocation, e.g. using slab allocators, memory pools, pre-allocation, etc. C# code in theory (ignoring things like intrinsics support and inline asm) can be as fast as C++ for tight loops, but in my exp…

C# has support for stack-allocated "struct" objects that avoid the GC. They have their limitations and gotchas, being somewhere between simple C structs and C# classes, but they exist. GC-based languages run games on many, many platforms. The problem, imho, is that you have to leave 90% of the language features on the shelf when you're doing your main loops in order to avoid triggering the GC. The gaming industry is…

I am also looking forward to the .NET Native C# compiler release.

Mostly as a way for young generations to finally grasp GC/memory safe != VM, as they seem to have been brainwashed since Java became widespread.

Re: Why C++ for Unreal 4

#56

Post by pjmlp »

CyberShadow wrote: post #14

There was a talk at last year's D conference how Remedy Games have used D as their "scripting" language: http://dconf.org/talks/evans_1.html I wonder if some of the same points would apply here. The short version of the talk is that D compiles much faster than C++, has limited C++ link compatibility (e.g. classes, but not templates), and overall has nicer syntax / language features than using C++ directly. Metaprogra…

Yeah C++ compile times will be a pain until a module system gets done.

This is why I follow with high interest the work clang guys are doing for the committee.

Re: Why C++ for Unreal 4

#57

Post by scott_s »

CmonDev wrote: post #39
xedarius wrote: post #8

I developed two titles with the Unreal Engine and whilst initially UnrealScript seems like an advantage it very very quickly becomes problematic. My favorite being the dependency of the C++ code on the script and the script on the C++, so if you're not careful you can end up being completely unable to do a build. As much effort as they put into the IDE it would always play second fiddle to Visual Studio. When I left…

They could also use C# instead of UnrealScript on top of C++. This way you would be able to leverage the Visual Studio while getting one of the best languages. It would make Unity3d guys welcome once they need something better as well. PS: I like the BluePrint though.

They would still need an interoperability layer, which was one of the main reasons for dropping UnrealScript.

Re: Why C++ for Unreal 4

#58

Post by Narishma »

beefsack wrote: post #38

It will be interesting if any major game engines pop up using Rust as the core language, or even Go. C++ has been the king of highly optimised game engines for so long, I can't help but feel it has become so entrenched in the industry that it will take something monumental to disrupt it.

I don't think it will happen with Rust until it becomes more stable with no breaking changes between releases.

As for Go, it's not very well suited to this domain. Or at least no better suited than Java or C#.

Re: Why C++ for Unreal 4

#59

Post by HeXetic »

It's important to note that what is being talked about in this post is not, "why we wrote the Unreal engine in C++", because it already was in C++. Many games, older Unreals included, had a separation between "code" and "scripting", where stuff like animations, weapon firing, etc. was written in scripts, in the belief that this would be easier to update as required vs. C or C++ code.

Doom 3 and previous Unreal engines had scripting languages; even the first moddable FPS engine, Quake, had a 'scripting language' of sorts -- Quake C, a sort of subset of C. id software turned back to pure code with the Quake 4 engine, however, recognizing the mistake that introducing the overhead of script-vs-code, and the limitations of scripts, outweighs any gains from being "easier to edit".

Re: Why C++ for Unreal 4

#60

Post by simias »

kibwen wrote: post #46
simias wrote: post #42

Earlier quoted context omitted.

That's a good lessons for people wanting to create a new languages too. One of the reasons C++ was successful in the first place is that it needs almost no glue to interface with C code. Contrast that with all the languages providing a more or less cumbersome FFI. Rust for instance looks very promising but you still have to go through the tedious task of redeclaring all the prototypes of the C functions before you ca…

Actually, one of the first tools to appear in the Rust ecosystem was a port of the "bindgen" program written for the Clay language, which has been solving the problem of parsing C headers for years now: https://github.com/crabtw/rust-bindgen/ There are also long-term plans for adopting this into the compiler itself: https://github.com/mozilla/rust/issues/2124

Ah, thank you, I knew I saw something like that when I looked into rust a while back, but there was no mention of it in the Rust FFI guide[1]. It should definitely be included in the compiler at some point, it's a vital feature IMO.

[1] http://static.rust-lang.org/doc/master/guide-ffi.html

Post reply on HN