views:

455

answers:

8

I am just wondering how some things work in gamedev:

  1. I know, that the performance is actually crucial so there is still (and I think never will be) no place to use managed languages/platforms as Java/.NET just because of their performance. But... recently I have read somewhere here on SO, that even though people creating games use C++ as a primary language, they actually do not use STL or Boost (or a lot of them). In think it has something in common with performance, right? If I am wrong, could you please tell me what are the reasons to avoid those libraries (that I think make developer's life much easier)? Is it because of licensing (Boost)? And what about EA's version of STL? Do other studios make their own versions too?

  2. How "close to metal" game programming really is? Do you go deeper and closer to the machine? Do you sometimes use Assembly for critical inner loops, or C++ is actually the lowest abstraction layer that you use at the moment? I assume that in such products where performance is the most important thing profiling is very, very common task - but are you sometimes forced to use assembly to speed some parts up, or good C++ is "good enough"?

Edit: Sorry, It may not have been clear, but I am interested in answers from people having game industry experience. I am not interested in some assumptions given by people who do not have commercial experience in game development. I am also not interested in examples of some niche-games created in C#/Java whatever. However if you know a product that looks better than FarCry2 (just and example, but your favourite modern great looking game name here), and is written entirely in Java/.NET, and has similar performance to FarCry2... do not hesitate to mention this product! Thanks.

+2  A: 

About 1:

I haven't tried EA's STL version, but I can confirm from my own game development experience that the STL can sometimes be a bottleneck. So far I was always able to find workarounds though.

Boost can be very helpful, but it really depends on the particular part of boost whether it's helpful or not for performance-critical code. For example, Boost::filesystem was very useful for me, whereas boost::signals was barely useable due to very poor performance. So I implemented my own signaling library using FastDelegates instead.

About 2:

Most of the time you will get away with regular C++ code. Once the game is running and you can identify bottlenecks with your profiler, you can start optimizing those pieces of code. And even then, you might not have to write any assembler code if you do it right.

For example, my custom-built 2d game engine runs without hardware acceleration. I developed it when 3D drivers were still quite buggy and most casual gamers have outdated graphics card drivers, so compatibility was more important than pure performance at that time.

Still, in our game latest game Gemsweeper, we are using a lot of alpha blending with 8-bit alpha masks and the game still has to run on 500 mhz cpu's. So alpha blending turned out to be a performance critical area.

To optimize this, I've used the VectorC compiler so that I could take advantage of MMX, SSE and the like without having to write assembler code. But the same code can be fast on one CPU and slow on the other (e.g. Intel vs. AMD), so I also compiled the alpha blending code several times with different optimization settings. The game runs a benchmark at runtime to find the fastest blitting module for each blitting method and uses that module from then on.

I've compared the result with some other 2d blending libraries, one of which claimed to be pure hand-optimized assembler and my engine had about the same performance in average, as measured on different CPUs.

Bottom line: Do not optimize without measuring first and think about alternatives before starting to write assembler. This usually wields good enough results and wil save you a lot of time.

Adrian Grigore
thanks for the great answer. As for the Assembly: I am not a person who just tries to find a place where it is possible to put some pure asm code, but I was just wondering if Assembly is still used today, if there are any situation that using assembler gives a real performance boost.
MaciekTalaska
There might be. But you're not going to know until you've 1) written your game to work without resorting to assembly, 2) replaced a section of your code with assembler, and 3) observed a noticeable performance improvement.
jalf
Processors have become complex enough that dropping into assembly is typically going to produce slower code. The one area that this isn't true is in using vectorized instructions such as SSE. Current compilers are notoriously bad at auto vectorization. As Adrian Grigore mentions there are compilers that just focus on that.
stonemetal
thanks for your comments! I think it is very valuable to point that is just SIMD/SSE what is worth to be optimized by using assembly language.I will Google to find out more about such compilers. Thanks again!!
MaciekTalaska
+3  A: 

I can recommend the book C++ for game programmers. It has an in-depth discussion of the performance cost of c++ features such as the STL, exceptions and RTTI. It also touches on having your own memory manager, and various common performance optimizations.

Appearlenty there is a new edition out, but it has a different author. What's up with that?

gnud
thank you for the link to this book. seems really interesting.
MaciekTalaska
+7  A: 

1. Contrary to some beliefs, the STL is quite optimized and not at all bad code. The reason for why most game studios don't use it is memory. You don't have as much control over memory allocation and deallocation as if you would write your own version of the STL containers. This is also the reason why managed languages are not preferred.

Writing your own containers will let you write cross platform code and do memory tracking easier. This is especially true on consoles where, for instance the PS3, requires detailed knowledge of the hardware in order to get the best performance out of it. Which usually in the end means that you need full control over memory flow between the PPU, SPUs and RSX.

2. Assembler is only "required" (in quotes since it's not actually required but helps) for very specialized operations, e.g. math library functions. What's more common is SIMD intrinsics which vectorizes the code. However, most studios have legacy code which is quite optimized and since these optimizations are quite low level it's not code that needs to change greatly between hardware generations. I'd say on consoles it's much more common that you use lower level code.

Flawe
ok, but I am still wondering about the use of STL. does it mean that smart pointers are also not used? generally: does it mean, that the C++ used in game development is very, very low level and the point is not to use any libraries not designed especially for game programming (assuming that those designed for game development are very, very optimized)? In short: is it rather "C with classes" than modern C++?
MaciekTalaska
Not at all. Smart pointers are used, and should be used in many cases. However, it's not hard to implement your own version of it and even make it better. What it usually means is that you really want to code your own helper utilities as much as possible because it gives you the best control over your code base. In this case, creating your own containers and smart pointers and whatnot is a relatively easy and fast thing to do, which you just have to do only once. Whenever you use a standalone library you give away control of your game, which you don't want to do.
Flawe
This seems to me more like a 'do it yourself' approach. I understand that one may not have such a control over memory allocation when using some library, but... if go this way: why not write your own OpenGL/DirectX-like graphics library? I am also wondering what is the actual cost of maintaining such libraries.
MaciekTalaska
That's exactly the point, a well optimized and generic library with STL-like containers and such don't have to be maintained, you write them only once. So it's worth it to write them. While writing your own graphics library implementation is out of the question. Think of how much it needs to be maintained and how many different GPUs you'll need to write drivers for. This is most likely what decides if you go for, say, a physics library or write your own. How much control do you want over it and will it be worth it to maintain and evolve it.
Flawe
+5  A: 

I know, that the performance is actually crucial so there is still (and I think never will be) no place to use managed languages/platforms as Java/.NET just because of their performance.

No, you don't know this. You think it, you want to believe it because you romanticize game development, and because you think high-level languages can't be fast. .NET performance is perfectly good enough for 90% of the games out there. And it's only going to get better. There is no inherent reason why managed platforms must be slower. They have the potential to be faster because they're JIT'ed. In practice, their performance tends to be about the same as reasonably good C++ code, much better than typical C++ code, and slightly worse than really good C++ code. And most big games use more than one language anyway. They use scripting languages, like Lua or Python, or some home-brewed stuff, all of which are orders of magnitudes slower than .NET.

Similarly, there is absolutely no reason why most of your game couldn't be written in .NET. And then the three really performance-critical functions can, if necessary, be ported to native C++ later.

But... recently I have read somewhere here on SO, that even though people creating games use C++ as a primary language, they actually do not use STL or Boost (or a lot of them). In think it has something in common with performance, right? If I am wrong, could you please tell me what are the reasons to avoid those libraries

Same as you're guilty of above... Superstition about game development. "Oh no, we can't afford to use other people's code! It's far too inefficient". Game development is stuck in the 80's in terms of programming practices and methodologies. In other words, don't worry too much about what other game developers do. If the STL or Boost make your code easier to write, then use it! And then, if you experience performance problems, profile it, and if necessary, replace that particular library component with your own.

But most of the STL is literally zero overhead. And 95% of the code in any game is not performance critical. Treat game development like you would any other programming. Don't treat it as some magical land where every line of code must be perfectly optimized and where normal rules don't apply.

And what about EA's version of STL? Do other studios make their own versions too?

As far as I know, no. EA made it partly for internal use, but also as input to the C++ community as a whole, as an example of what they (and a lot of game developers) would like to see from future revisions to the standard (it was submitted to the standards committee as well)

jalf
And if there are sections where .NET's performance just isn't good enough, write that section in C/assembler/whatever, then use P/Invoke to call your native code.
Ian Kemp
Hm... I *actually* read about it (I've read it in some interview with a person working for EA Games, and what he said was like: "there will never be CPU/GPU fast enough"). And NO you're wrong, performance of .NET is *not* good enough for games. Take a look at all game development related job advertisements. Any C# (not for Tools programmers)? No! I know what I am talking about, believe me.Scripting languages: yes, but it is mostly Lua because of its good performance and small memory requirements.But scripting is not used for graphic related tasks, rather for AI or something similar.
MaciekTalaska
This superstition is **NOT** mine. I have read about it, and person who wrote it, is working in games industry for a couple of years, so I do not understand your strong opinion - especially because you just don't seem to have any experience in games industry, right?Game programming is **NOT** like other programming. In most business app performance of code itself is actually not what people are worrying about (unless it is so slow that is unusable). Different type of problems, different scaling... IMO these worlds are not comparable.
MaciekTalaska
@Ian Kemp: you're joking, right? read about P/Invoke performance...c'mon people... no assumption, no **wishes** that .NET/Java is great for gamedev: it is **not**.
MaciekTalaska
The number of C# game development jobs have *nothing *to do with the performance of the language. If it did, I'd like to know why there aren't tens of thousands of Fortran gamedev positions. And LOL, are you *seriously* telling me that Lua performs better tha .NET?
jalf
And well done, you've *talked to a person in the games industry*. Well done, so have I. Some of them are idiots, who think it's best to do things the way they were done in the 80's. Their fear of losing performance leads them to write crappy code which can't be maintained, is buggy and... which there is no time to optimize, ironically. The ones who aren't idiots are the ones who realizes that game development, with its primadona attitude, has missed out on 20 years of improvements in methodologies in the field of software development.
jalf
But you're right. The superstition is not just yours. It is shared by some professional game developers too. But luckily, not all.
jalf
Frankly speaking I have not spoken to **one** person from game industry. But there is no point in some numbers. Lua is used for different things, and the memory footprint of Lua seems to be not so big as compared to .NET. I wouldn't call people who would like to have more control that .NET/Java offers - idiots. Is that so hard to understand that your wish that there was more games created in .NET/Java is just a wish? Look at all AAA titles. Any of them written entirely in Java/.NET? Don't think so...
MaciekTalaska
I am not saying that number of jobs offered in games industry where .NET/C# is the requirement is what describes the situation perfectly, but it **does** tell a lot about what is being used and what not. .NET/Java are only used as a platform for tools and some kind of prototypes. They're not using for writing games (AAA titles).It is strange, that you're forcing opinion that is not true. .NET/Java are not widely used in gamedev, period.
MaciekTalaska
There is one thing that you may be right: the attitude to software development, software craft, methodologies etc. I have heard that there is a problem with all of them in *many* game companies. But still - I would not made such a stong opinions as you do, especially not having experience in game industry.
MaciekTalaska
Of course the number of jobs says a lot about what is being used. And I never claimed that .NET was widely used. I simply said that actual performance isn't the reason why it's not used. Inertia is. Some of it is justified (If you've got a huge C++ codebase, you're not going to throw it away and start over in .NET), and some of it not ("We can't afford to use a language that's less than 15 years old. It *must* be slower, right?")
jalf
By the way, of the people you've asked in the industry, how many have *tried* writing their game in .NET before denouncing it as "too slow"? How many have tried writing it in .NET and then optimizing it before throwing it away in favor of the C++ code which *also* has to be heavily optimized before it's any good? Like I said above, there are good reasons why existing companies stick with C++. That allows them to reuse the code they have. And it runs on consoles as well as PC. But it doesn't mean that .NET is "too slow for games". Eve Online has most of their server code written in Python.
jalf
Eve Online is not IMO a good example. I wanted to ask about games that focus on the visuals.I haven't heard about such a game being developed in different language than C++.I am actually writing my own casual game in C++ and in C# - just to compare the performance. And as far as I remember some of the people I have talked to actually tried C#. Maybe the thing is that C# is not portable to consoles (and developing on consoles seem to be more and more important).Maybe C++ will loose its dominant position in gamedev some day but I don't expect it to happen in the nearest future.
MaciekTalaska
A server which is able to serve 25,000 players simultaneously is not a good example of performance-critical game code? I beg to differ. ;)But yeah, portability is definitely a big deal, no doubt about that. Most of the money is in console games, and .NET just isn't an option on PS3 or Wii. It is available to some extent on 360, but only the cut-down compact framework, with an inferior JIT compiler and GC. So yeah, I'm definitely not saying .NET is a replacement for gamedev code *in general*. Just that if you're on a platform it supports, and write decent code, performance is good.
jalf
Sorry, 45,000 concurrent players on the same server. (They hit that number back in January, presumably they've reached higher numbers since then). Anyway, still pretty respectable considering other MMO's like, say, WoW, are struggling with 3-5000 players per server.
jalf
About games that focus on visuals, remember that all the really performance-critical stuff there, is offloaded to the GPU, so the programming language makes even less difference there.By the way, good idea with writing your game in both. Do you document it on a blog or something? Sounds interesting, would love to follow it.
jalf
can't you just understand that server side programming is a little different? it is possible to use python, java .net for that, and still benefit from the great performance. **but** the thing is that a lot of work is being done by the server (apache, iis, whatever else). I think that I have already told you (couple of times) what kind of games I thought about when I was creating this question.
MaciekTalaska
yes, you're right that most of the stuff is actually processed on GPU itself, but I think that there are some things connected with loading/releasing resources that may work different with different platform / language. As for my game I was just making some test and now I am thinking which library for .net should I choose: XNA does not seem to be the best choice, and since there is no MDX supported by MS anymore... (yup, I am aware that there is this OpenSource version of MDX). I'll need to think about it.
MaciekTalaska
No, neither Apache or IIS or anything like that are involved in this. So how is server-side programming "different"? We are not talking about WEB servers. This is a custom application written to run a huge and complex game, not serve web pages. I'm sorry, but it sounds like you're the one failing to understand "server side programming".Anyway, for DX wrappers, SlimDX is probably worth checking out. It is made by some very skilled guys, and it is by far the best managed DirectX library available for PC development. Low overhead, and very well designed.
jalf
ok, I though that Eve online is something more like Ogame. My bad. I am not an expert in server side programming but what I really wanted to know is the performance of a game as a standalone desktop app that is aimed to generate some outstanding visuals (engine itself). Something more like demo-scene coding.Yeah, I was thinking about SlimDX, I have actually ported some of my old stuff that was using ManagedDirectX to SlimDX and it seems that SlimDX works very good. I definitely need create something bigger to be able to compare performance (between native DX/C++ and C#/SlimDX).
MaciekTalaska
A: 

No, you are largely wrong. Both .NET and Java have been used in commercial games, certainly on Windows (and probably on consoles too).

STL is also used widely, I know that quite a large proportion of amateur games developers use it.

Probably the main reason for not using STL is inertia, and using third party libraries/engines which do not.

I imagine that historically on some platforms, good STL implementations were no available, especially on RAM-limited stuff like PS2.

MarkR
Would you care to give an example of a console game written in Java or .NET? Or even a high-profile, successful PC game written in Java or .NET?
Ori Pessach
Care to back up that assertion with examples? I would posit that Java and C# are never used in any commercial games that are not played inside a web-browser. Many games have a scripting layer (Python or Lua are often used), but that is only for gameplay elements that are not performance-critical.
Alan
XNA works with C#, and that can be used to publish PC games (indeed I'm writing one for PC at the moment using XNA/C#, of course many games have been published on xbox360 using XNA (although not to great success, that's less to do with performance and more to do with advertising and shoddy game design)
Martin
No, I am **NOT** entirely wrong. I am interested in games industry, and .NET/Java are not being used so widely. I haven't heard about big games written entirely using .NET/Java. The (.NET/Java) could have been used for some parts of the game, but definitely most of the game itself was written in C++.And do you **REALLY** know that STL is used widely? Because I have heard that in some big studios it is **NOT** used widely. So... is it your own game industry experience? Or just an assumption?
MaciekTalaska
@Martin: it is great that you're developing your own game, but XNA does not seem to be the best platform for game development. It is quite easy to develop something on XBox not having to worry about the 'real' SDK, but somehow no big game companies are interested in releasing their titles using XNA, right? I was actually asking for answers from people who have game industry experience. I also tried XNA and even Managed DirectX before, but it is not the point that it is possible to create game in .NET... it is about performance.
MaciekTalaska
My experience is entirely secondhand - I do know several people who do work in the games industry, but I don't do it myself.
MarkR
A: 

You can find out for yourself (to a degree) by looking at game SDKs.

Almost all the id Tech 4 games (DooM III, Prey, Quake IV, ET:QW) have SDKs out, complete with physics, script, AI, math, etc. systems included. The only asm used is for specialized math code, everything else is pure C++.

Crytek has a Crysis SDK out (you'll need the game installed to install the SDK though) and Far Cry SDK.

Valve has the Source SDK available to anyone who has purchased a Source game through steam.

There are a lot more if you look. A lot of the code isn't particularly clean or flexible (sometimes not even fast), but I suppose it's easier to adjust things in code you've written as opposed to monolithic libraries full of hard to understand template-fu.

floodyberry
Those crytek sdks you are talking about are mods... you will less likely find low level codes there... ASM codes can be found in the game engines, which none of us will get to see since they are propreitory.
Shawn Mclean
Have you bothered to look at how much code is handled by some of the sdks? Splash Damage had to write a painfully twisted Game Script -> C++ generator just to run ET:QW fast enough, all of that code is included in the SDK. The entire ragdoll physics code is included with all id Tech 4 SDKs, including over 1mb of accelerated math code.Did you look at CryEngine/CryCommon/Cry_XOptimise.h? There is a lot of asm there.SDKs don't contain code that is only run when someone makes a mod, it's the core server and client logic for the game.
floodyberry
Considering I'm the only one who provided concrete examples of code running in real triple A titles, I'm glad you guys are downvoting and leaving bogus comments!
floodyberry
+2  A: 

It is true that in game development, STL is not used. In spite of what certain people always rush to claim, they also never use Java or C# or other managed languages.

I'm not talking about small X-Box Live Arcade downloadable games or web browser games, or such things. I'm talking about high-end development in AAA games.

They don't use STL. However, they do use their own custom implementations that look a lot like STL. There will be smart-arrays, there will be hash tables, there will be smart pointers, they just won't be STL.

Consoles have some performance characteristics that are very different from PCs. Even game projects that exclusively target PC are usually using codebases that have been used for console projects in the past. A lot of tweaking goes into making the basic template structures work as desired.

Most game studios also want code that they can adapt to other platforms. Locking into an implementation from MS/Sony/Nintendo makes for a lot more pain when it comes time to port the game to a new platform. The provided template libraries (which aren't necessarily STL to start with) are often less than stellar. At least they are that way early in the hardware cycle when a studio is ironing out the engine they plan to keep using for the next five years.

At the studios I've worked at, I've certainly seen a fair degree of "not-built-here" attitude to dismiss third party code. Sometimes it's justified, sometimes it's not. In the case of basic data structure templates, it typically is.

As for your second question, assembler is occasionally used. But only in isolated situations where a large volume of math needs to happen very frequently. An entire engine might contain two or three smallish files of asm blocks.

Alan
thanks for the comment. It seems that all the people who have some gamedev experience are sharing the same point of view. And all those 'game developer wannabies' are just trying to force their own point of view, that is actually far from being true.What you say really makes sense. This is the kind of answer I was expecting, thanks.
MaciekTalaska
+2  A: 

We use 'STL' (ie. the standard C++ library) and a small amount of Boost. However some of it is avoided or frowned upon (std::map, std::list, boost::shared_ptr) typically for the over-exuberant memory allocation policies or poor cache coherency. These can typically be worked around, eg. with custom allocators, but instead we have other approaches to the same problems with their own benefits.

As for how close to the metal it really is, it depends. In our project C++ is the lowest level we go. In another project in this studio, there is a little assembly, especially on the non-PC platforms. These days in certain projects you're just as likely to be limited by the GPU as by the CPU so the days of low level code optimisation are getting fewer and the days of optimising shaders and art assets are growing.

Be wary of claiming that Java/.NET etc is never used however. Not everybody needs the performance of FarCry2 (which is a pretty excessive spec) which is why you're seeing more and more games written in managed languages with C++ just for optimisation.

Kylotan
Thanks for your answer. I gave the example of FarCry2 just because those titles that compete with outstanding visuals, those AAA titles are interesting to me. There may be a lot of casual games, quite nice looking, written in everything from Python to Java/.NET, but this is not exactly the type of games I was thinking while writing this question.
MaciekTalaska
I'm not talking about casual games when I mention games written in managed languages: I mean games like EVE Online, Toontown Online, Civilization IV, VtM:Bloodlines. They have a lot of C++ for optimisation, but C++ used to have a lot of assembly for optimisation too, and now assembly is almost gone. Even all the Unreal games have all their logic driven by UnrealScript, which is essentially a proprietary managed language. These languages will continue to grow in importance.
Kylotan