[=;18441]
I genuinely don’t want to hear about python, javascript, java nor c# where games (AAA games) are involved.
Go here Google Publishes C++, Go, Java and Scala Performance Benchmarks - ReadWrite,
see how some of the languages compare to C++.
Why would anyone choose anything but C++ for AAA game development is beyond me.
But it is not even about the performance.
The deeper you go with coding the more you starting realize that C# or Java are not only not easier but lots of things are far more difficult to do with them than with C++.
Guys, is C++ perfect? Absolutely not. Is it better for games development than C# or Java or any other modern language. Without any doubt.
[/]
Not sure why you have such a high disdain for other languages. Normally, your game logic will literally run circles around a render frame. Sometimes your game thread can make multiple game logic passes before the render thread even has a chance to consume the frame
So this is how things work in a few game engines I’ve seen that use a multithreaded renderer. There are normally 2 approaches (trying to stay brief no one needs a wall of text)
Approach 1:
Game/Main thread produces the logic for the frame and submits this to the multithreaded renderer. After this frame has been submitted, it does a lot of busy work. Like run physics jobs in parallel, animation jobs for next frame, etc. Afterwards, it may stop and wait for the render thread to come back
Approach 2:
Game/Main thread runs parallel with the render thread. Game thread runs through logic for the frame and then submits this data when it’s done. But unlike approach #1, it doesn’t stop and wait on render thread. It keeps going, working on the next frame. It is possible render thread will ‘miss’ a game frame. So to present this case the Game thread is busy making sure all the data he is going to pass on contains complete information, tricking render thread into thinking he has a ‘complete’ up-to-date frame copy
In both cases, your game thread is so fast, he is waiting on rendering. Render thread is often busy computing shadows (Cascade shadow maps, etc), running post effects, running the deferred renderer, etc.
My point is that in most engines you usually have plenty of CPU left for a high level language.
Where problems creep up in AAA games or rather, porting these games, is getting that game to run on a lower target. This is when you might look at your scripts with a scope.
My last title I worked on it was running at 60 fps. I think the game had 2 script VMs running and we were still GPU bound. Not CPU bound. We didn’t have to change not a single script when we down-ported it to other platforms
So my main point is for sure you have plenty of bandwidth for other languages.
[edit] I just made a very broad statement there. And of course I only refer to using these other languages for Game logic. Plus, physics was run on another thread. On our target platforms, we had at least 4 cores available to run jobs and at least 3 you have 100% control over without the ‘system OS’ interrupting