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

111–120 of 125 posts

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

#111

Post by shmerl »

pjmlp wrote: post #87
dikaiosune wrote: post #48

Earlier quoted context omitted.

Are you saying those are good things or bad things in the context of games? As I commented elsewhere, it's not that I don't think that Rust's safety isn't important, but it's not the only worthwhile element of the language and I think it's good to recognize that its safety guarantees can eliminate many "non-safety" bugs in many programs.

I am saying they are bad things, then again game developers aren't known for worrying 1s about safety anyway, specially if that implies 1ms less, even if that isn't an issue for the game being developed.

The major benefit is simply avoiding all kind of crashes which plague many games.

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

#112

Post by jongraehl »

Every one of his complaints has a good solution, albeit some not widely known. Except compile time, single source file or otherwise - the compiler is using lots of smarts and lots of library headers on your behalf.

That said, author has done a good job explaining his thought process in taking the rewarding-at-every-step path, given he's not a C++-wrangling junkie.

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

#113

Post by exDM69 »

pcwalton wrote: post #108
exDM69 wrote: post #81

Earlier quoted context omitted.

> vector math without operator overloading is gross. Many C compilers can use normal infix operators with SIMD vectors and it will have better performance than C++ operator overloading (especially in debug builds). All you need is a typedef. typedef float vec4f __attribute__ ((vector_size (16))); vec4f a = { 1, 2, 3, 4 }, b = { 5, 6, 7, 8 }; vec4f c = a * (a + b); The typedef is slightly different for Clang, but that…

> In C++ with operator overloading it's easy to do stupid things like in-place addition (e.g. operator+= for a vec4f) or start transposing matrices in place. This will make the compiler emit memory load/store instructions when you'd want to have these values in registers. That sounds like a failure of inlining. If you're at the point where a single stack spill makes a difference, you won't want to pay the cost of the…

> Modern compiler optimizations make what you describe not a problem anymore.

Yes, it should get inlined, but I've seen this fail in a recent-ish GCC (4.6 to 4.8 or so). And there's still the issue of debug builds being slower even if the compiler works perfectly in optimized builds.

Operator overloading will only work with SIMD if you write your vector class using intrinsics or SIMD extensions anyway. If you're doing scalar loads and stores, you can't rely on getting SIMD instructions in the output.

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

#115

Post by hellofunk »

Wow, I had to change the brightness and contrast setting on my monitor just to read this article. What is the strategy behind this darkish font against black background? I wish more websites geared towards a reading audience actually provided a nice reading experience.

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

#116

Post by na85 »

loup-vaillant wrote: post #89
greyman wrote: post #60

Earlier quoted context omitted.

As a long-time C++ coder, I need to add that project-specific prohibition of some C++ practices is a pretty normal, even recommended thing to do. Introducing such prohibitions is not a fault of C++. Also, I observed that "bad experience with C++" is often related to someone using, while not completely understood, some more advanced C++ paradigm.

> project-specific prohibition of some C++ practices is a pretty normal, even recommended thing to do. So there's a need to subset C++. I wonder. If we took the union of the most common subsets, would we have all of C++, or only parts of it? Which parts of C++ are unsuitable for any project? If there is any, it is totally the fault of C++ if we have to subset it. Historical reasons yada yada, I don't care: a language…

JavaScript is widely subset, and yet it remains inexplicably held in high esteem.

Could it be more that C++ is a decent language that is fashionable to hate on?

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

#117

Post by forgettableuser »

unscaled wrote: post #93
crafn wrote: post #83

Earlier quoted context omitted.

Good that I succeeded at avoiding ranting. I find it really hard to keep from throwing absolutes. Almost everything is possible with C++, that's true. Some things require a lot of engineering though. Like full program reflection, fast debug builds, and fast (below 5s) builds. Funny that you mention the decoupling of state and logic, because I see that as a non-issue in C. State is a struct, logic is a function. There…

You've said most of your build time was linking, so wouldn't you get the same build times with C? Templates would slow your build time a lot though, so they come with a price. C++ would never beat C on build times, but C never came close to Pascal, back in the day, and I'm pretty sure C# still beats the guts out of C with hands tied. :) > Funny that you mention the decoupling of state and logic, because I see that as…

> You've said most of your build time was linking, so wouldn't you get the same build times with C?

C++ generally incurs a price on link times too. For example C++'s stronger type system creates more burden on the name mangling, like there is actually a difference between an int and long, even if they are the same size on the system. Then if you have code that doesn't make this distinction, overloaded functions need to be generated which creates more generate code bloat. Then if you throw templates into the mix, C++ generates a ton of symbols for every permutation. This is why C++ object files are usually much larger than C object files and why the linking process is so much slower.

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

#118

Post by loup-vaillant »

na85 wrote: post #116
loup-vaillant wrote: post #89

Earlier quoted context omitted.

> project-specific prohibition of some C++ practices is a pretty normal, even recommended thing to do. So there's a need to subset C++. I wonder. If we took the union of the most common subsets, would we have all of C++, or only parts of it? Which parts of C++ are unsuitable for any project? If there is any, it is totally the fault of C++ if we have to subset it. Historical reasons yada yada, I don't care: a language…

JavaScript is widely subset, and yet it remains inexplicably held in high esteem. Could it be more that C++ is a decent language that is fashionable to hate on?

JavaScript held in high esteem? You can't be serious? That language is way too flawed: equality operator that's not transitive, wicked scoping rules, semicolon that you can omit but really shouldn't… And you're telling me this poor Self copycat is held in high esteem? How? Because it took over the web? That's not enough.

As for C++… That language is just too big for its own good. It tries to be too many things to too many people, and as a result is almost never the best choice. (Discounting code already written and available expertise of course. I'm judging the language, not the ecosystem.)

The idea of C++ is a good one, under a couple conditions: first, it must be tuned to a domain or a way of programming. Second, it must not try to be goddamn source compatible with C. If we're writing a language, we might as well correct C's mistakes along the way.

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

#119

Post by pcwalton »

exDM69 wrote: post #113
pcwalton wrote: post #108

Earlier quoted context omitted.

> In C++ with operator overloading it's easy to do stupid things like in-place addition (e.g. operator+= for a vec4f) or start transposing matrices in place. This will make the compiler emit memory load/store instructions when you'd want to have these values in registers. That sounds like a failure of inlining. If you're at the point where a single stack spill makes a difference, you won't want to pay the cost of the…

> Modern compiler optimizations make what you describe not a problem anymore. Yes, it should get inlined, but I've seen this fail in a recent-ish GCC (4.6 to 4.8 or so). And there's still the issue of debug builds being slower even if the compiler works perfectly in optimized builds. Operator overloading will only work with SIMD if you write your vector class using intrinsics or SIMD extensions anyway. If you're doin…

> Yes, it should get inlined, but I've seen this fail in a recent-ish GCC (4.6 to 4.8 or so)

Seems like a pretty bad GCC bug then, one that should be fixed upstream.

I really dislike it when code avoids functions because of fear that they won't be inlined (or to try to work around compiler bugs to that effect), because doing this dramatically reduces code maintainability and safety in exchange for very little benefit, given the inline hint keyword and __attribute__((always_inline)).

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

#120

Post by taloft »

krisdol wrote: post #95
flohofwoe wrote: post #61

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…

Most are not writing their own engines anymore. In this day of mobile and web gaming, indie developers everywhere, and game engines like Unity and UE4 being so accessible, I think more game developers are writing games in Java, JavaScript, C#, and other garbage collected languages -- not to mention "visual programming" of Unity and UE4. If you're writing a game engine in C/C++ today you're probably never going beyond…

Performance will be back if VR gets adopted. At 90 fps, you have around 11 milliseconds to update your game state and render views for each eye. That is not much time. C#/unity and scripting languages will have a noticeable penalty compared to native C code. Bloated engines will likely suffer as well.
Post reply on HN