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

81–90 of 125 posts

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

#81

Post by exDM69 »

amagumori wrote: post #31
microcolonel wrote: post #10

Earlier quoted context omitted.

I don't think you're addressing the concerns which made him choose C. In his case: debugging is complex, compilation is slow, name mangling is unreliable, global state is abound. He makes no mention of inline assembler, nor does he encourage premature optimization. He talks instead about a concrete problem he had: the typical performance of operations was not good enough, thus no single optimization would help much.…

meh - imo, even if C++ is a ridiculously bloated beast, it has some things that are indispensable for game programming that C doesn't. vector math without operator overloading is gross. being able to have generic containers with templates is really useful, even if templates are gross. encapsulating functionality in classes is always useful, and you can get a lot of use out of inheritance without overusing it. these t…

> 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's just one line. This code should work with GCC, Clang and the Intel C compiler. MSVC doesn't do this, but I don't write code for MSVC any more because I can compile compatible object files with Clang.

In my experiments, I've noticed that you get the best performance by passing vectors and matrices by value, not by pointer or reference. It also makes the API nice, because you can return matrix values, e.g. `mat4x4f mvp = matrix_product(projection, matrix_product(model, view))`. In some nasty cases you might need to add force_inline attribute, but most of the time the compiler will inline the functions anyway.

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.

> being able to have generic containers with templates

Generic containers are somewhat of an issue with C, but most of the std::containers are not suitable for some game development tasks (this is why projects like eastl exists). I prefer using intrusive containers in C, similar to how the Linux kernel deals with linked lists and red-black trees. Even the C++ standard library (the GNU one) is internally implemented this way, the "generic container" is just a thin type safety shim on top to avoid template bloat.

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

#82

Post by animal531 »

tormeh wrote: post #65
jcranmer wrote: post #49

Earlier quoted context omitted.

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 are…

Same problem writing the engine in C#. You often run into memory and GC problems that are a pain to work around.

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

#83

Post by crafn »

unscaled wrote: post #45
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 was positively surprised by the constructiveness of the article itself. You'd usually get Linus' style rant about how C++ sucks so bad and C is the epitome of simplicity and design. I wholeheartedly agree with you that both languages are lacking, and I'm also waiting until Rust or another language grows mature enough to replace both of them in most cases. But I think most of the main points you describe as impossib…

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 would need to be a really convincing argument to make me wrap the hundreds of game object components I'll have to two objects each.

C has some differing cognitive cost, which C++ doesn't have, that's for sure. I think we have just differing personal preferences on which is worse :P (There are real-world situations where I'd choose C++ though)

The network point is valid. Implementing it was mostly a nice learning opportunity. I haven't yet decided if I want to keep it or not. It currently lacks safety and proper compression, so if I get serious about it I'll probably make all network data go through validation functions, which helps with both compression and handling hostile data.

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

#84

Post by exDM69 »

spoiler wrote: post #66
na85 wrote: post #34

Earlier quoted context omitted.

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…

Most C++ compilers these days should have zero cost exception handling, meaning that the non-exceptional path should be free. This works by making the compiler add exception handler data to the executable file, ie. telling where the catch() blocks are. When an exception is thrown, the stack trace is analyzed and the appropriate catch handler is found by searching for the return addresses in the exception handler data.

This can make C++ with exceptions faster than C with error checks because there's no branches to check for every error condition. Using __builtin_expect for marking the error conditions as unlikely may mitigate this issue.

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

#85

Post by exDM69 »

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…

> 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 claims

I agree with the OP on all three counts. I don't think RAII is very nice (python-esque with-statement would be nicer IMO), exception safety is really a mental overhead unless you restrict exceptions to a minimum and the copy-assign-move semantics do add a bit of work to every class you introduce.

These are not outrageous claims, they're rather valid opinions. Feel free to disagree but I'm siding with OP on this one.

Overall I dislike C++'s value based semantics, not because it's inherently bad, but it's just so different to any other (reference based) languages that only a small minority of programmers know how to work with them. Attaching complex semantics to types (overloading, templates) and virtual functions/inheritance (when overused) makes reading code much harder and often you need to resort to stepping in the debugger to find out where a function call actually leads.

Well written C++ can be really nice at best, but unfortunately most C++ code bases out there seem to be either a bastard mix of C, Java and C++ styles or over-the-board boost-ey template mess. Neither of these extremes hits the sweet spot.

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

#86

Post by crafn »

cLeEOGPw wrote: post #36
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…

I think one of the main reasons why he did what he did is his motivation, or lack of it while working with C++. Whatever rational arguments would point out to C++ will be essentially meaningless if he is not happy writing with it. That's why discipline is so important in any work. Motivation can get you just so far. It is highly volatile and unreliable. I think it's safe to assume that the author soon will get tired…

Absolutely you should take the text with a grain of salt. The reasons I chose C are very personal.

I can entertain the idea that my desire for simplicity is just a fad. I suspect that I wouldn't move to something like Python (I use it for other purposes though), because I don't like optimizing. I want a mindset which helps producing code with reasonable productivity, and of which performance I don't need to worry much. But yeah, it's possible that I'll change my mind and write an article about how I was so wrong before :P

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

#87

Post by pjmlp »

dikaiosune wrote: post #48
pjmlp wrote: post #46

Earlier quoted context omitted.

What many that issue that kind of statements forget, is that safety is also a means to keep the game experience clean. Exploiting buffer overflows, stack corruptions and friends is how we get to earn extra lifes, bypass hard levels, get extra ammunition and so on.

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.

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

#88

Post by crafn »

HelloNurse wrote: post #79
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…

I see unwillingness to adopt the modern and relatively extreme ways to use contemporary C++ well, only the old and simple painful ways to use "C with classes" with serious issues. For example, the paragraph about loading and saving game state postulates "using the ideas of polymorphism and encapsulation", automatically throwing a lot of pointers and vtables in the way of reading and writing a binary blob like in the…

> A serious C++ engine with a "data oriented" design would have the same arrays of primitive types and dumb structs as its C counterpart, merely dressed as std::vector or std::array

Yeah, I agree. Including the "full C++" to the comparison was just trying to avoid having to argue about which is the "right" subset of C++ for engines, which is somewhat besides the point. The main problems I have with modern, data-oriented C++ are mostly compile times, slow debug builds and non-trivial reflection.

Some don't mind those, and be happy.

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

#89

Post by loup-vaillant »

greyman wrote: post #60
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…

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 you have to subset is still worse than the subset itself.

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

#90

Post by golergka »

crafn wrote: post #76
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…

The need for high performance meets with my creative interests. (But I also have technical interest in making the engine). I also value the ability of being able to implement extraordinary features to the engine in a whim, which is hard with large general use engines. I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.

> I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.

This "class of games" includes more or less everything that a single developer without a very costly art department can produce. If your game can not be implemented with a prebuilt engine, it's really something extraordinary.

Post reply on HN