It have come to my attention that although general rendering performance guidelines suggest minimizing draw call count and render state changes, most big AAA tiles do only very minimal optimizations on this or no optimizations at all, for example i PIX'ed few popular games to see whats up:

Mass effect - ~1000 draw calls per frame, 20000(!) render state changes and ~1000 draw primitive UP calls per frame
Civilization V (DX11) - 3000+ draw calls, thousand or so set pixel/vertex shader, 500+ set texture, etc per frame on average

Whats up with this nonsense? Why none even bother to do some optimizations on this matter?

Really no clue?

Maybe they already optimized what they could...
Maybe they decided that performance was good enough and further optimizing was not worth the effort...
Maybe they were quickly approaching a deadline...

You can only minimise so much before the work involved in doing so becomes overly onerous and you get into diminishing returns. Maybe these titles genuinely do have ~1000 unique object states per frame, and therefore can't go any lower? 1000 draw calls is really quite low for a large complex scene, so I certainly wouldn't call it "very minimal or no optimizations". "No optimizations" in a 1,000,000 triangle scene would be 1,000,000 draw calls, after all.

Not true.

Look at this(ignore the gray stuff): http://img202.images...112/greybar.jpg

Each yield icon (green/gold coins on map) gets a draw call(!), each hex grid overlay (white border around EACH hex) gets a draw call, ignoring the fact that you could do that with one draw call even without using instancing - and with simpler code! With all this i think in screen shot we are getting well over 10k+ dip's, and its NOT fast.

Im not a pro graphics engineer, but with a 10 minute of taught you could render all yield icons in two draw calls and one set texture (they are using DX11 FFS!), and whats even more obvious, you could overlay hex grid with one draw call or none at all if you just sample it when drawing terrain...

My taught is that they just do not give a damn... Same thing for my loved Blizzard - in WoW when drawing terrain chunks, instead of doing simple test "if (stage0Texture != textureToSet)" they just go what a heck and don't do nothing, ignoring the fact that wow is heavily cpu bound and targeted at wide range of hardware, low-mid end including (released in 2001!) - and i tested, i have build the same thing, and doing this simple optimization gave 11% performance gain, for about 20 lines of extremely simple code.


So my taught is - if you are indie developer making your game, don't event try to optimize this stuff, no one is doing it anyway and being fine - even when targeting low-mid end hardware. Doing this kind of optimization have proven to be useless and don't listen to 101 texts of saying batch batch batch, omg draw calls, etc - just write your game flexible and start worrying if you are reaching over 3k in average scene. ;P

I don't think there are noobs working for the large companies. I'm pretty sure they know they could have done better, but when deadlines are approaching and the publisher keeps the pressure up and there are other tasks with higher priority AND you know that your game will sell shitloads either way..

I hope your advice to indies to not give a f*** was just sarcastic.

Thanks Hodgman!

This indeed is also issue when you don't have strict time limit, but are creating and planning to release indie game in timely fashion - and maybe this is even worse, because you get impression that your schedule is OK, throughout you are wasting tons of time on least important details, and not focusing on right parts of code - this and some other aspects of indie game design are the main reason why so many games get abandoned unfinished.

I have seen articles talking about general guidelines for finishing your hobby game in timely fashion and finishing it at all, but they seem to lack relation of real code to fashion and priorities of coding, have not seen a text saying : you probably better skip dip/state change optimizations, as it provides a huge time sink and will delay your project without giving much in return, as instead, there are a lot of information how dips are root of evil and such Also primary focus for most people when concerning code is - FAST! and not fast in sense of development time, but in terms of milliseconds.

Someone really should construct some guidelines for this matter, that are down to earth and based on practical, real world examples and experience. Basically how to write code "fast(development time) and fast(code execution time)", and whats good balance in REAL situations.One way of doing this is to produce some sort of performance impact index, based on some sort of reference processor and gpu, saying - "System to minimize dips/state changes - general guide - Avoid", "Easy to use art-game pipeline - general guide - High Focus" etc