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

41–50 of 125 posts

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

#41

Post by comex »

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…

Incidentally, a tip: C11 has basic generic/overloading support based on macros. So even if you can't get "a + b * c + d", you can at least get "add(a, mul(b, c), d)". The implementation is ugly, but if you only need it for one thing, it doesn't really matter.

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

#42

Post by dikaiosune »

pjmlp wrote: post #39
anp wrote: post #28

Earlier quoted context omitted.

Only responding to one element of your comment -- but I think that Rust's safety features are over-marketed in my experience. The safety Rust offers is only part of a package that provides high-performance high-level abstractions over functionality that is normally very bit-twiddly in C. So far, my favorite thing about Rust is not its safety, but how easy it is to write good performance software using abstractions th…

I think they are marketed exactly well. If it wasn't for the uptake of UNIX, we probably would never had to discuss about memory corruption in 2016, other than writing stuff like device drivers. There is now a whole generation that thinks C was the very first systems programming language, the compilers were as good on day 1 as they are today and it has became some kind of sacred cow. http://www.itsecdb.com/oval/defin…

I don't think Rust's safety guarantees are over-marketed because they aren't important, but because many of the benefits of the language/stdlib/tooling are available to people who don't frequently have to deal with memory corruption. It's not that the safety isn't valuable (I just about pulled all my hair our implementing custom data structures in C++ last time I did it), but that most developers think it's not as useful as other marketable elements of the language.

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

#43

Post by [deleted] »

fizixer wrote: post #4

> I have to choose between writing duplicated code, writing a code generator, or tedious macro stuff for generic code. Code-generation all the way. Use an expressive language like python/lua/tcl/lisp/scheme to work on a higher layer than C. Two-language programming (one GC scripting, the other C) beats the heck out of C++, in terms of best of both worlds: expressivity in higher layer, performance in lower layer. C++…

[deleted]

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

#45

Post by unscaled »

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 impossible in C++ are actually completely possible. It means moving away from the 90's paradigm of using C++ to implement deep class hierarchies with design pattern, but after all C++ is a multi-paradigm language. If you can do data-oriented design in C, you could most certainly do it in C++, and the abstractions C++ provides actually make it easier.

In essence, I would separate game objects to a logic instance and state objects (pure structs) and use smart pointers with a generation-counter to point the logic instance, which in turn would have smart a pointer to the state struct. The smart pointer would overload the dereference operator and transparently update the logic instance to get the new vtable if needed.

This decoupling of state and logic could do many nice things, such as serializing the entire game state in a very clean way, and pure state structs would not be harder to parse than C structs (they would essentially be C structs), so you can still have your memory editor.

The main difference between C and C++ here would be the cost abstractions, both cognitive and performance-wise. I have to admit I've never ran into standard abstractions significantly slowing optimized debug code, except for standard library containers. I'm not a game programmer though, so YMMV. I get the cognitive cost argument, but for me the cognitive cost of C (namely having boilerplate noise scattered all over hiding the interesting code and having to be super-extra-careful with memory management) is higher than than the cognitive cost of internalizing all the layers of abstraction in C++.

If you're programming a network game, I still think you'd do your users a better service if you don't dismiss safety offhand. There's a whole class of memory-safety bugs which would never surface during normal play, but could still be exploited with specially crafted packets. Of course, C++ wouldn't give you perfect protection either.

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

#46

Post by pjmlp »

dikaiosune wrote: post #26
shmerl wrote: post #19

Why not Rust for example? If I'd be making an engine, I'd tried that.

"Safety-enforcing languages like Rust are going somewhat off already by definition, as they're focusing primarily on safety, which is not the focus for most game code." I don't really agree with this assessment (I think rust's "safety guarantees" really amount to amazing compile time programmer assistance), but that's their stated reason.

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.

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

#47

Post by Kurtz79 »

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

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

#48

Post by dikaiosune »

pjmlp wrote: post #46
dikaiosune wrote: post #26

Earlier quoted context omitted.

"Safety-enforcing languages like Rust are going somewhat off already by definition, as they're focusing primarily on safety, which is not the focus for most game code." I don't really agree with this assessment (I think rust's "safety guarantees" really amount to amazing compile time programmer assistance), but that's their stated reason.

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.

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

#49

Post by jcranmer »

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.

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

#50

Post by iainmerrick »

Apocryphon wrote: post #7

Has anyone attempted using Objective-C for game development outside of iOS gaming? It'd be interesting using it as an OO language substitute for C++.

Yes, I used Obj-C to port a game from iOS to Android. Mac and Windows versions coming soon, also in Obj-C! I use Clang, GNUstep and my own rewrite of UIKit.

Possibly this is just Stockholm syndrome, but the more I use Obj-C, the more I like it. It uses reference counting, so memory overhead is low and consistent, and running time is consistent. It's not fast, true, but in my case most of the running time is spent in OpenGL anyway. Plain C is always there at your fingertips for crucial inner loops. Newer features like properties and for-each loops make it fairly pleasant to use. The standard Foundation library is pretty well-designed.

The one thing it's possibly missing is generics (Apple added that feature recently but I haven't tried it yet). Without generics, it feels a bit like a reference-counted Go -- that slight scripting language feel but with native speed.

The one big downside... On non-Apple platforms, the tooling is very patchy, and new features can take a while to arrive. If Apple is really serious about open-sourcing Swift, that could help a lot. I imagine there'll be more interest in new shiny Swift than crufty old Obj-C, but Obj-C is still a nice little language.

[Edit: capitalization of GNUstep :)]

Post reply on HN