21–30 of 179 posts
It's a lost cause: there's no such thing as "sane" or "orthodox" C++. Instead, use something actually sane like Go. Or Rust, if you really must (first bad pun is free, then it's 50 cents each).
Anyways, C++ is much easier to manage than any GC language for a real time application such as this. And your Rust "pun" is a rhyme.
It's a lost cause: there's no such thing as "sane" or "orthodox" C++. Instead, use something actually sane like Go. Or Rust, if you really must (first bad pun is free, then it's 50 cents each).
http://fabiensanglard.net/doom3/index.php http://fabiensanglard.net/doom3/interviews.php#qc++
New hobbyist engines pop up from time to time and then they fade into memory. Why is this going to be different? Not to be too grumpy but game engines are a weird thing cause they are such complex beasts and usually the people using them have invested a lot of time in learning them. It's fun to make a new engine, but it probably doesn't have the community nor interest to cover the hard 10 to 20% that inevitably come…
Do features or concepts kicked around in the "hobbyist" engines ever influence or inform the mainstream engines?
It's a lost cause: there's no such thing as "sane" or "orthodox" C++. Instead, use something actually sane like Go. Or Rust, if you really must (first bad pun is free, then it's 50 cents each).
Yet Go uses the oh-so-error-prone return value error checking that has been so successful in C :/
It's a lost cause: there's no such thing as "sane" or "orthodox" C++. Instead, use something actually sane like Go. Or Rust, if you really must (first bad pun is free, then it's 50 cents each).
Go is a bad choice for game with its unavoidable GC. And Rust is simply too complicated for a person wanting sane C++. D or Nim (or even C!) would make more sense.
Surely there are better reasons to disregard Go for gamedev by now.
Earlier quoted context omitted.
Go is a bad choice for game with its unavoidable GC. And Rust is simply too complicated for a person wanting sane C++. D or Nim (or even C!) would make more sense.
Is there not a point where GC overhead becomes negligible? There have been production examples of Go maintaining sub-millisecond GC pauses with a multi-GB heap under a server workload. https://twitter.com/brianhatfield/status/804355831080751104 Surely there are better reasons to disregard Go for gamedev by now.
I keep wondering if it's not possible or if there's just not a lot of overlap between Go programmers and gamedevs? Wish someone knew.
Wow it seems to contain a full level editor written in vala, a language I hadn't heard of. It seems to be a high level language similar to C# but with a native compiler and some different semantics (RC instead of a tracing GC for example). Is vala widely used?
Earlier quoted context omitted.
Yeah, I'd like to know why you'd still use C++ at all if you find Orthodox C++ appealing. It would seem easier to just write C. Unless I'm missing something (I probably am; don't write enough of either one to have an informed opinion, which is why I'd love to hear more about this).
RAII is incredibly attractive, especially if you disable exceptions.