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

131–140 of 178 posts

Re: Why C++ for Unreal 4

#131

Post by srean »

VikingCoder wrote: post #120
greggman wrote: post #95

Earlier quoted context omitted.

The biggest advantage of scripting for me has been 1. Co-routines Co-routines (co-operative multi-tasking?) mean you can do stuff like while (isWalking()) { advance(); yield(); } This is effectively 'yield' from Python, C#, etc.. You can implement this in C++ by swapping stacks and calling setjmp but there's usually issues. 2. Iteration time You can usually swap script code live. This project aims to fix that for C++…

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

That is precisely the beauty of coroutines: your code can look like threaded code but you can get the performance of an event-loop. Put another way, with coroutines you get most of the advantages of an event loop but very few of its disadvantages. (You get concurrency only, not parallelism, well this is almost true). For cooperative multi-tasking, threads are unnecessarily resource hungry and wasteful. They hoard resources although most of the time they are doing nothing just waiting. This is usually fine if you think yours is the only application that should be running on the hardware at that time, but typically you want to share the hardware with others.

Remember not everybody has the luxury of working on a system where you can spawn 10,000 threads without breaking a sweat.

However this territory of literally hundreds of thousands of programmed agents participating in a game does not seem to be very populated. Perhaps part of the reason is that very few languages had efficient (this eliminates stack copying), scalable and portable support of coroutines. This is starting to change, but not as fast as I would like.

I think C is to be blamed for the long under appreciated status of coroutines. It is one abstraction that C left out, although the VM C had as its execution model (the PDP) had excellent support for coroutines at the instruction level. C exported pretty much every abstraction of the underlying instruction set, but not coroutines.

EDIT: @VikingCoder Replying here as HN wouldnt allow me to respond till some time has past. Yes I have looked at asio although just scratched the surface. It looks very interesting, as far as I know they are not threads though (which is a good thing), they use macro and template metaprogramming trickery to turn producer-consumers into one big switch case. If you interested in coroutines and seamless interaction with C++ I can recommend http://felix-lang.org

Re: Why C++ for Unreal 4

#132

Post by angersock »

HeXetic wrote: post #125
angersock wrote: post #83

Earlier quoted context omitted.

Brief rant: Quake 1 ran a virtual machine, which QuakeC compiled down to. Quake 2 ran native code via DLLs. Quake 3 ran either VM code or native code--depending on how clever you wanted to be, you might need to break into the native code. There wasn't some "mistake" about using scripts-vs-code, because they would actually compile down to executable bytecode. This made it much easier to load mods over the network if y…

As a Doom 3 modder myself, I experienced considerable headaches juggling the interplay between scripts and code, especially since so much stuff (like firing a gun or moving around) spanned the two systems so inelegantly.

I think it was handled somewhat better in older engines.

Doom3 seemed a bit of an odd duck.

Re: Why C++ for Unreal 4

#133

Post by VikingCoder »

srean wrote: post #131
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.…

That is precisely the beauty of coroutines: your code can look like threaded code but you can get the performance of an event-loop. Put another way, with coroutines you get most of the advantages of an event loop but very few of its disadvantages. (You get concurrency only, not parallelism, well this is almost true). For cooperative multi-tasking, threads are unnecessarily resource hungry and wasteful. They hoard res…

Have you experimented with Boost Context and Boost Coroutine?

Re: Why C++ for Unreal 4

#134

Post by loup-vaillant »

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.

If the safer type system gives the devs an unwarranted sense of security, they might write less tests, be less careful in their design, or wait longer between audits and other sanity checks.

If on the other hand the devs understand which classes of bugs aren't ruled out in Rust, then sure, you will end up with fewer bugs.

Re: Why C++ for Unreal 4

#135

Post by kansface »

munificent wrote: post #122
crucialfelix wrote: post #104

Earlier quoted context omitted.

The slightly obscure music programming language SuperCollider [1] added co-routines about 10 years ago and they became one of my beloved techniques. Was very glad to see them come to python and soon to mainstream javascript. Boost has a c++ implementation but it looks quite different: http://www.boost.org/doc/libs/1_55_0/libs/coroutine/doc/html... [1] http://supercollider.github.io edit: pythons new asyncio stuff loo…

> Was very glad to see them come to python and soon to mainstream javascript. I really need to get around to writing a blog post to explain this in detail since this misapprehension is endemic. Python and JavaScript do not have coroutines, they have generators. Lua has actual coroutines. The latter is dramatically more expressive than what you can do with what Python, JavaScript, and C# offer. This mistake drives me…

Py3000 added support for the "pass a generator" construct that you care about: http://simeonvisser.com/posts/python-3-using-yield-from-in-g....

Re: Why C++ for Unreal 4

#136

Post by Guvante »

archagon wrote: post #5

On the other hand, I feel that tools like Unity are successful precisely because they let you tinker with your game in a WYSIWYG kind of way. It's really liberating to be able to work inside such a tight feedback loop, and it's a little weird to see a modern game engine distancing itself from that approach. (But maybe I'm missing something. What exactly is the role of the Unreal Editor in UE4? Is it mostly for things…

> So why is Tim Sweeney saying that C++ is replacing UnrealScript for gameplay code?

Blueprints are a weird entity, not really code, but definitely similar.

I think the major difference is they are heavily event based and probably have severe performance restrictions placed on them, which is the major difference. If you want a real time-slice you need to do it in C++.

Re: Why C++ for Unreal 4

#137

Post by Guvante »

Pxtl wrote: post #51
berkut wrote: post #24

Earlier quoted context omitted.

Exactly. What's most distressing is people (as normal) are completely ignoring the garbage collection overhead, which is mostly where the advantage of having complete control is, in terms of micro-managing your memory allocation, e.g. using slab allocators, memory pools, pre-allocation, etc. C# code in theory (ignoring things like intrinsics support and inline asm) can be as fast as C++ for tight loops, but in my exp…

C# has support for stack-allocated "struct" objects that avoid the GC. They have their limitations and gotchas, being somewhere between simple C structs and C# classes, but they exist. GC-based languages run games on many, many platforms. The problem, imho, is that you have to leave 90% of the language features on the shelf when you're doing your main loops in order to avoid triggering the GC. The gaming industry is…

There is heavy rumors going around that a new version of C# with a more well defined memory model is in the works.

Re: Why C++ for Unreal 4

#138

Post by Guvante »

jokoon wrote: post #99

finally. Now, to make the gameplay programmer and level designer's job easier, you still have to build well made and documented building blocks. It's either that or hire people who do know how to talk a statically typed language. Might be good news for the job market, I always found it weird to have people making games who were not really competent in programming. always baffled me. I guess you can still force people…

Their blueprint system is phenomenally powerful without including any actual code.

Heck it even allows live preview of how it is executing.

Re: Why C++ for Unreal 4

#139

Post by crucialfelix »

munificent wrote: post #122
crucialfelix wrote: post #104

Earlier quoted context omitted.

The slightly obscure music programming language SuperCollider [1] added co-routines about 10 years ago and they became one of my beloved techniques. Was very glad to see them come to python and soon to mainstream javascript. Boost has a c++ implementation but it looks quite different: http://www.boost.org/doc/libs/1_55_0/libs/coroutine/doc/html... [1] http://supercollider.github.io edit: pythons new asyncio stuff loo…

> Was very glad to see them come to python and soon to mainstream javascript. I really need to get around to writing a blog post to explain this in detail since this misapprehension is endemic. Python and JavaScript do not have coroutines, they have generators. Lua has actual coroutines. The latter is dramatically more expressive than what you can do with what Python, JavaScript, and C# offer. This mistake drives me…

Great write up - make that a rough draft for your post. I was going to edit my comment earlier to point out that coroutine is not generator.

I realized this limitation one day while trying to do it in python. You cannot just yield another stream.

SuperCollider has proper co-routines: http://danielnouri.org/docs/SuperColliderHelp/Core/Kernel/Ro...

and the pattern library is built entirely around embedding in streams and yielding others streams. it uses this for very interesting numeric music patterns.

Python 3.4 also now has co-routines: https://docs.python.org/3.4/library/asyncio-task.html

esp this is interesting:

result = yield from future – suspends the coroutine until the future is done, then returns the future’s result, or raises an exception, which will be propagated. (If the future is cancelled, it will raise a CancelledError exception.) Note that tasks are futures, and everything said about futures also applies to tasks.

result = yield from coroutine – wait for another coroutine to produce a result (or raise an exception, which will be propagated). The coroutine expression must be a call to another coroutine.

Javascript does/will have simple generators

Post reply on HN