Why do video game engines use mainly C++?

C# is used as an interface to the c++ engine.

ok

High performance and familiarity. There was this project of remaking The Elder Scrolls Morrowind as OpenMW. It was originally done in D, but they switched to C++ so more people could contribute.

Games are for children.

Best compromise between speed, features, portability and tooling for years. It's honestly kind of a shit language when you look at all the modern alternatives and what they bring but c++ got inertia and decades of proven work.

Giving $187k to one guy who never published source code or a playable demo until the project was dead. Sad!

>Why do video game engines use mainly C++?
Speed + power

They can't even make decent front-end for graphics. There are multiple solutions with different level of abstraction like Vulkano, glutin, glium (all these were made by one dude, he is an autist of some sort), gfx-rs, gfx hal. gfx-rs is the most developed one, but the authors dropped it and are doing gfx hal now.
Right now Vulkano and gfx hal are the only that could possibly see the future.

C++ is the most powerful programming language in the world.

Attached: meatand.jpg (460x345, 36K)

it doesn't matter
games are mostly assets, not code

you can't even quantify that, but games have a shitton of code anyway so that's incorrect

assets are produced using code

It's because C++ is very fast and has deterministic memory management with regard to performance, which is important to ensure hitting e.g. 60 fps (or other) targets.
A language with a realtime gc and very high speed would work as well but there is none suitable at this point.
Urho3D is the best engine this side of UE4. UE4 is good but the editor is a broken mess and explodes every 5 seconds, which makes using it a pain in the ass beyond any pain in the ass.
For 2D, rolling your own literally takes less time and effort to learning one so it's best to always do that. For 3D, rolling your own takes man-years to get anything even remotely production-ready so you're better off with one of these engines.
Note that it's not usual to write a desktop game in C++ too, however, just the engine and speed-critical algorithms. The rest is typically written in a scripting language (such as lua, C#, UE4's strange scripting shit, angelscript, etc.)

I can understand why, I just started learning Rust and it's really grating how anal the compiler is. Stuff that I could trust to just work in other languages and reason to be safe is treated as unsafe.

Inertia. The reason most game engines use C++ is because a lot of groundwork for 3d has been done using C/C++ in the 90s, so the developers of new engines stuck with it.

There's nothing preventing you from making a game / game engine in java or rust

unity is great, /v/
stop believing the meme

>assets take up more drive space so they're more important than the code running the game in the first place
big if true

Attached: really_thinking.png (2688x2688, 173K)

In java: the gc (azul's products only work with hardware-assisted gc, there are no current solution for java to guarantee realtime pauses, you'd have to be even tighter on garbage management than you already have to be in C++).
in Rust: the gay compiler (you'd end up writing 90% unsafe code simply because you don't want to rewrite your entire code from scratch just to add a simple feature and stay safe).

GC is not a problem if you aren't a brainlet and constantly instantiate new objects, especially not with Java 11 and the zGC
Rust: Stop writing your architecture as a big ball of mud where everything needs access to global mutable state. Use an ECS

C++ has the power of C and works with objects.
C++ looks like something made by a indian CS guy, but still is good

>Rust: Stop writing your architecture as a big ball of mud where everything needs access to global mutable state. Use an ECS
Lrn2 data oriented design faggot.

OOP, low level, memory and garbage management can be done manually

Yes, that's what I said

What is inherently wrong, safety wise, with accessing global mutable state? Is it an issue with threading or something? Can't you mutex that shit? I'm left wondering why Rust disallows things quite often, but I don't think The Book covers this.

Doesn't stop firefox from leaking memory like a sieve

Looks like you were fortunate enough to never have to write any medium-or-higher-sized software in rust. Never try, it's horrifying. Not for any reason you seem to think though.
The problem with gc are the maximum latency and the impact on program throughput. You can't accept much more than 2ms latency at most, but you also can't let your program grind to a near-halt from being interrupted every 5ms for 2ms.
zGC can in fact hit these targets, but has the disadvantage of being a copying gc, which is fine for desktop games but not so much for other platforms. Also, the use of load barriers instead of write barriers might have negative impact on games as opposed to general programs.
The real hurdle with zGC, though, is that it WILL leak memory if you allocate faster than it runs, in order to guarantee this low pause time.

Global mutable states are actually THE way to bypass the rust compiler limitations. It's the only guaranteed method not to have to rewrite everything from scratch every 2 days. Not doing that makes it very hard for the checker to accept your program as it grows in complexity.

>Effective Rust Programming: How to Dodge the Borrow Checker

>C++ is the best
This.

>C++ is the best option for video games
That's not a question, please write properly.

This.

Because it's as fast as C while having a whole bunch of extra nice features that make expressing game concepts and managing large projects easier.