[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Search] [Home]
Board
Settings Home
/g/ - Technology



Thread archived.
You cannot reply anymore.




File: bbva-open4u-unity.png (669 KB, 941x571)
669 KB
669 KB PNG
Why do video game engines use mainly C++?

C++ is the best option for video games?
>>
>>68416844
unity uses C#
>>
>>68416859
Unity is a poor quality product
>>
>>68416859
>unity uses C#
Unity uses more langs than C# for managed code
But the engine is still in C++
>>
>>68416880
yeah but you claim all games use C++ and use a screenshot from unity for your post.
>>
>>68416844
C became the industry standard because of John Carmack, and C++ is the closest thing to C that supports using game objects.
>>
>>68416844
You can use whatever you want. It basically just comes down to
1. OOP being a good fit for games (I don't generally like OOP but it just makes sense here from an abstraction point of view, though I do encourage pure ECS for performance).
2. C++ being performant
3. There being a large body of competent programmers that understand and prefer to work in C++

I'm looking forward to a Rust gaming engine
>>
>>68416937
>Rust gaming engine
http://arewegameyet.com/
>>
>>68416844
C++ was pretty much the only game in town if you wanted portable reasonable performance. Java was just coming out and a lot of better languages like Ada we're gimped by reliance on commerical compilers. It was easy to implement a c++ compiler for anything that could run c and pretty much everything could. Now all the tools and game design stuff is written with c++ in mind. You aren't going to find very good libraries or resources if you wanted to write a high tech game in like Ocaml or something. There isn't any technical reason why you can't use another language.Naughty dog had their own lisp dialectic that compiled to PlayStation assembly code that was just as performant but much more expressive than c or c++. They had to switch to c++ so they could share tech with other Sony studios I imagine other game companies feel similar pressure not to rock the boat. There are game engines for any big language anyway if you want to develop something in Haskell or Java libraries are the only thing stopping you.
>>
>>68416880
t. enginedev that's never made a game
Link related is the ultimate fate of a typical C++ enginedev
https://www.kickstarter.com/projects/joshparnell/limit-theory-an-infinite-procedural-space-game/posts/2270873
>>
>>68416859
C# is used as an interface to the c++ engine.

>>68416880
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.
>>
>>68416844
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.
>>
>>68417121
Giving $187k to one guy who never published source code or a playable demo until the project was dead. Sad!
>>
>>68416844
>Why do video game engines use mainly C++?
Speed + power
>>
>>68416965
>>68416937
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.
>>
File: meatand.jpg (36 KB, 460x345)
36 KB
36 KB JPG
>>68416844
C++ is the most powerful programming language in the world.
>>
>>68416844
it doesn't matter
games are mostly assets, not code
>>
>>68418861
you can't even quantify that, but games have a shitton of code anyway so that's incorrect
>>
>>68418861
assets are produced using code
>>
>>68416844
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.)
>>
>>68418600
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.
>>
>>68416844
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
>>
>>68416880
unity is great, /v/
stop believing the meme
>>
File: really_thinking.png (173 KB, 2688x2688)
173 KB
173 KB PNG
>>68418861
>assets take up more drive space so they're more important than the code running the game in the first place
big if true
>>
>>68420903
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).
>>
>>68420936
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
>>
>>68416844
C++ has the power of C and works with objects.
C++ looks like something made by a indian CS guy, but still is good
>>
>>68420973
>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.
>>
>>68416844
OOP, low level, memory and garbage management can be done manually
>>
>>68420995
Yes, that's what I said
>>
>>68420936
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.
>>
>>68420973
Doesn't stop firefox from leaking memory like a sieve
>>
>>68420973
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.
>>
>>68421030
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
>>
>>68416844
>C++ is the best
This.
>>
>>68416844
>C++ is the best option for video games
That's not a question, please write properly.
>>
>>68421003
This.
>>
>>68416844
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.





Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.