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

Why C++ for Unreal 4

forums.unrealengine.com

Post reply on HN
Print view View original

171–178 of 178 posts

Re: Why C++ for Unreal 4

#171

Post by VikingCoder »

anon4 wrote: post #165
VikingCoder wrote: post #120

Earlier quoted context omitted.

I've been using threads to do co-operative multi-tasking, for a while now. Every place that I'm tempted to write an event-driven finite state machine, or something similar, I spawn a thread instead. I get to write synchronous code, which feels much more natural to me. For instance my actor, running in a thread, calls a function like advance(). That drops data into an object, and wakes up the main thread, and blocks.…

Don't you still need to carefully use locks everywhere? For me the one reason to use coroutines instead of regular threads is that coroutines are cooperative multitasking, rather than preemptive. Which is what I want for when I have a bunch of concurrent but not parallel processes working on shared data.

I have a main thread, an actor thread, and a single object that they use to communicate. So yes, I have one lock, around the single object they use to communicate.

I'd need one lock per actor thread and its communication object.

I say again, this works in my problem domain, and probably wouldn't work in other domains.

Re: Why C++ for Unreal 4

#172

Post by dbaupp »

JoeAltmaier wrote: post #170
dbaupp wrote: post #153

Earlier quoted context omitted.

Of course it's possible to write correct C++ code, just like it's possible to write correct assembly code. The point is the extra care required: every piece of code needs to be very carefully authored to ensure it's correct, to avoid the myriad pitfalls.

Or you can just trust the language. And if its not right, or not the way you plan to use it, what then? You're stuck unless the language also permits you to roll your own.

Rust does allow you to implement low-level things in itself, by giving an escape hatch into C/C++-like unsafe code (i.e. risk-of-incorrectness is purely opt-in, rather than always-there).

Examples of things efficiently implemented entirely in the standard library in pure Rust (well, with some calls into the operating system/libc): Vec, the std::vector equivalent. Rc, reference counted pointers (statically restricted to a single thread). Arc, thread-safe reference counted pointers. Mutex. Concurrent queues. Hashmap.

Re: Why C++ for Unreal 4

#173

Post by pcwalton »

detrino wrote: post #169
pcwalton wrote: post #129

Earlier quoted context omitted.

I've described this many times in the past, but here are a few things that modern C++ does nothing to protect against: * Iterator invalidation: if you destroy the contents of a container that you're iterating over, undefined behavior. This has resulted in actual security bugs in Firefox. std::vector v; v.push_back(MyObject); for (auto x : v) { v.clear(); x->whatever(); // UB } * "this" pointer invalidation: if you ca…

Use after move by itself is not undefined behaviour.

It is for most of the important types that people move; e.g. unique_ptr (results in null dereference).

Re: Why C++ for Unreal 4

#174

Post by midnightclubbed »

flohofwoe wrote: post #128
midnightclubbed wrote: post #123

Earlier quoted context omitted.

By removing the power from your design team you are creating more work for the software engineers and removing tools from the creative team. An ideal scripting language: - Allows designers to build complex gameplay elements, define complex ai behaviors, create gameflow with minimal work from the software engineers. - Handles memory allocation/destruction behind the scenes - Does not crash the game when an error occur…

Did you use an existing scripting language, or roll your own? How did you handle debugging and profiling, and did you limit access to control constructs like loops, variables, etc..? Did the scripting system have some sort of per-frame budget/quota? Curiously interested...

Rolled our own - one I helped write, one I used. Both followed a stripped down C-like syntax (minus pointers). Both had conditional statements, loops, variables, simple structs, arrays (range checked), float/int/bool.

On the projects I worked on script performance wasn't too much of an issue, the scripts were used to control state and flow, not to do any number-crunching.

If you control what is exposed to the scripting then engineering will know when design asks for access to something that should be implemented outside of scripts. Which in my experience seemed to have minimized performance issues.

One concerns when switching over to a development system such as Unity or Unreal 4 is that your gameplay 'scripts' have access to the entire engine. It seems very easy at that point for your game to turn to unintentional spaghetti.

Re: Why C++ for Unreal 4

#175

Post by lobster_johnson »

bjz_ wrote: post #163
lobster_johnson wrote: post #144

Earlier quoted context omitted.

I have high hopes for Nimrod [1] in that regard. Unlike Rust and Go, Nimrod is able to be almost as fast as C/C++ without sacrificing syntax; Nimrod's syntax often looks entirely like Python. For example, here's the example from the Nimrod home page: # compute average line length var count = 0 var sum = 0 for line in stdin.lines: count += 1 sum += line.len echo "Average line length: ", if count > 0: sum / count else:…

Nimrod is a great language, but it has different goals to Rust. You get better expressiveness, and cleaner code, but you don't get the huge benefits of Rust's static type system. It depends on which you value more - I think there is a place for them both though.

Nimrod's static type system looks comparable to Rust's; are you referring to Rust's safety guarantees?

If so, I believe Nimrod's support for immutability gets you pretty far, but I have not looked very deeply at it. For example, implements an explicit "IO taint" mechanism reminiscent of Haskell.

Re: Why C++ for Unreal 4

#176

Post by flohofwoe »

midnightclubbed wrote: post #174
flohofwoe wrote: post #128

Earlier quoted context omitted.

Did you use an existing scripting language, or roll your own? How did you handle debugging and profiling, and did you limit access to control constructs like loops, variables, etc..? Did the scripting system have some sort of per-frame budget/quota? Curiously interested...

Rolled our own - one I helped write, one I used. Both followed a stripped down C-like syntax (minus pointers). Both had conditional statements, loops, variables, simple structs, arrays (range checked), float/int/bool. On the projects I worked on script performance wasn't too much of an issue, the scripts were used to control state and flow, not to do any number-crunching. If you control what is exposed to the scripti…

Interesting, thanks!

Re: Why C++ for Unreal 4

#177

Post by maccard »

steveklabnik wrote: post #124
maccard wrote: post #121

Earlier quoted context omitted.

If BF4 was written in Csharp, or java (or rust or go?? I'm sure it would still have just as many bugs. One of peoples biggest complaint is the kill shots that you don't see, but that's a design choice (client side hit detection).

Of course, it's impossible to speculate without seeing the codebase, but considering that Rust makes several classes of C++ bugs impossible at compile time, I'd be hard-pressed to imagine that a Rust version wouldn't be less buggy.

Less prone to certain kinds of bugs, sure. But logical errors, not necessarily.

Re: Why C++ for Unreal 4

#178

Post by boulderdash »

srean wrote: post #148
boulderdash wrote: post #145

Earlier quoted context omitted.

@srean - can you provide a link to the PDP support for coroutines? I would like to read more.

By the time I got within touching distance of any computer the era of the PDPs were long over. I have learned from John Skaller that they could exchange control between two stack frames in a single assembly instruction. "Exchange Jump" is what I think it was called. You will have to search the assembly manual for PDP-11 for more. Wikipedia has some details http://en.wikipedia.org/wiki/Coroutine#Implementations_in_as.…

Hi srean - thanks for that recap. I just did some more digging on this and tried to understand the assembly versions of coroutines. They were very spartan. It was just: POP the next address from the stack into TEMP, PUSH the current PC, then set the PC to TEMP. Notice that there isn't any linking or parameter passing.

Overall, it has been fun reading on all the variants of this idea.

side note: in my first job, there were a few PDP-11s in the lab that I was responsible for. We never turned them on though.

Also, the PDP 10, which you mention above, was one of the most revered machines by hackers.

Post reply on HN