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

C or C++ for my game engine?

crafn.kapsi.fi

Post reply on HN
Print view View original

61–70 of 125 posts

Re: C or C++ for my game engine?

#61

Post by flohofwoe »

Completely agree, this is why most game developers use only a subset of C++ as "C with classes", and at the end of that thought process some are going back to C completely (I haven't made the jump yet though, but have been pondering this for at least 2 years). What I still like about C++:

- user-provided code called when an "object" goes out of scope

- operator overloading sometimes makes sense

- simple template-meta-programming sometimes makes sense (but could be replaced with other sorts of code-generation)

3rd party libraries are usually a pain to integrate when they have a C++ interface, and usually simple when they are just a C header, and when they can simply be dropped in as source into the project.

A good middle-ground is probably to build the building blocks in C, this way they are way better reusable then writing C++ code, also across languages, and tie the low-level buildings blocks together in whatever language one likes (even interpreted languages).

[edit: formatting]

Re: C or C++ for my game engine?

#62

Post by greyman »

crafn wrote: post #29
nly wrote: post #24

A good article, but what disturbs me is that the author, while obviously aware of relatively good C++ and programming practices, has somehow arrived in a place where he discounts essentially all of C++s core competencies... like claiming RAII is "far from optimal", that exception safety is "a constant mental overhead", and that copy and move semantics involve writing "a lot of code". These are fairly outrageous claim…

>These are fairly outrageous claims, and it all smells of total burnout, and losing sight of the forest for the trees, to me. Maybe, I don't know. I have been a lot happier with C though, while still writing some C++ code during the year.

Interesting, since I feel just the opposite. In C++, most of the time, I can write the precise intent of what the code should do, and I can also choose the level of abstractness, without compromising on performance!

I think the main trick with C++ is to learn the best practices first, and only use those one thoroughly understood.

Re: C or C++ for my game engine?

#63

Post by Rusky »

crafn wrote: post #25

Author here. I'm positively surprised, constructive discussion on internet! There's been some discussion about using Rust. Rust is an interesting language, and has definitely potential substituting C and C++ in some domains. The main reason I'm not so interested in using it is for game development, is because it's more complicated than C (like C++), and the complications are a bit off from what I'd want (like in C++)…

I doubt you'd have the sort of trouble with pointers and unsafe blocks that you suggest. Most typical pointer patterns don't even require lifetime annotations, let alone bypassing the borrow checker.

I also think the "convenience features" are a pretty big deal. Generics with traits are a pretty big value add for their complexity, and to me affine types take away a lot of the complexity of C.

Re: C or C++ for my game engine?

#64

Post by Rusky »

Kurtz79 wrote: post #47
crafn wrote: post #25

Author here. I'm positively surprised, constructive discussion on internet! There's been some discussion about using Rust. Rust is an interesting language, and has definitely potential substituting C and C++ in some domains. The main reason I'm not so interested in using it is for game development, is because it's more complicated than C (like C++), and the complications are a bit off from what I'd want (like in C++)…

This is a nice talk from Jonathan Blow (Braid's author) about the necessity of a new language for game programming as an alternative to C++, and why new languages like Go or Rust are not apt to the task: https://www.youtube.com/watch?v=TH9VCN6UkyQ

He barely mentions Rust and only to dismiss it as a "big idea language" because it's memory-safe. Not a very interesting critique, IMO- he doesn't talk at all about any of the other features of Rust that improve on C and C++.

Some interesting ideas otherwise, though.

Re: C or C++ for my game engine?

#65

Post by tormeh »

jcranmer wrote: post #49
Qantourisc wrote: post #33

A lot of games run on Mono/.net Java etc. IIRC these languages have far more overhead. (I could be wrong.) So unless you suspect you need >9000 fps OR you are going to be doing a LOT of processing / complex game you might not need to worry about it ?

The JVM can run pure Java code to within 2× of native code (although it has a pretty weak vectorizer, so if you're getting vectorized speedups in native code, Java won't get you that). However, calling a native function from Java is a really high overhead call. Which means that the core engine likely can run at essentially the same speed, but the graphics is going to be slower.

Note that this is the default, standardized behavior. If you're willing to use Oracle (and I think by extension OpenJDK)-specific features then there are some functions with "unsafe" in the name that allows you to hand over memory directly to native code, instead of copying it over. The default behaviour is to copy all memory passed in and out of the JVM, so as to avoid native+java+GC messing with the same memory area (potentially at the same time).

Re: C or C++ for my game engine?

#66

Post by spoiler »

na85 wrote: post #34
dahart wrote: post #13

> 5. realize that I shouldn't be using some parts of C++ (exceptions, stdlib) > 6. start to ponder if I really need even the good parts of C++ This reads like wisdom and maturity to me; unfortunate, but not surprising, that people are quick to judge. Last game studio I worked at, we wouldn't have given up C++, but there were frequent conversations about its pitfalls and complexity, and quite a few rules and conventio…

I don't use C++ for anything serious, can you explain what's wrong with exceptions and the std lib?

For exceptions: - A bit unpredictable (hard to optimize)

- Introduce a lot of exit points which are hard to find

- They deviate from the "pay what you use," since they generate some extra code

- They can introduce some nasty performance penalties (I experienced this myself a few yeas back, the compilers might be smarter these days, maybe)

About the stdlib: There's a "myth" that often times the stdlib/stl is slow and doesn't do what you expect (unless you've thoroughly read the documentation, which everyone should do anyway). I can't say I was personally affected by this since I also use C++ for nothing too serious. I said "myth" because the argument against the slowness it that this is an outdated notion.

Re: C or C++ for my game engine?

#68

Post by tinco »

golergka wrote: post #51

You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…

Unity is written in C. That the game logic is written in C# is hardly relevant as you explain. In fact this guy might still embed C# at some point if he wishes for his logic to be less painful to write.

The author states at the beginning that his goal is writing an engine and only after that write a game. You are right on all other points though, most people working on game engines simply never get to the making a game part. There's simply too much to do.

I spent a couple years' working together with a friend every now and then on a game+game engine in C#. We did get past the game engine phase because it was kept simple (ECS + box2d and simple monogame 3d renderer) but we eventually gave up because even though game logic was progressing swiftly assets were just a pain in the ass.

Most low level engineers (as we are/were) underestimate the work it requires to get a proper asset pipeline set up. You're never going to build a 3d game if you can't load cheap 3rd party assets with their animations and materials. And then the level designer which is basically just another game in your game.

We went with UE4 as a change of pace and man is it librating not to have to worry about the limitations of your homebrew engine anymore. In UE4 literally anything is possible (you have the full source after all) and its always less work.

Re: C or C++ for my game engine?

#69

Post by kartan »

tinco wrote: post #68
golergka wrote: post #51

You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…

Unity is written in C. That the game logic is written in C# is hardly relevant as you explain. In fact this guy might still embed C# at some point if he wishes for his logic to be less painful to write. The author states at the beginning that his goal is writing an engine and only after that write a game. You are right on all other points though, most people working on game engines simply never get to the making a ga…

Unity is written in C/C++ (http://answers.unity3d.com/questions/9675/is-unity-engine-wr...) And I guess by the answer that C is just for the API for other languages. As there is no way of doing that in C++ without an standard ABI(https://en.wikipedia.org/wiki/Application_binary_interface).

Re: C or C++ for my game engine?

#70

Post by greggman »

golergka wrote: post #51

You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…

I don't personally think it matters all that much even on AAA games. Unreal has GC. Take a look at the games made in Unity. Plenty of AAA or close to AAA games. Cities Skylines, Firewatch, Ori and the Blind Forest, Pollen, Endless Legend.

I've written several game engines in the past. I hope to never do it again.

Post reply on HN