I just read the following article which I believe has been mentioned here before as well.
As I have a fair understanding of the DirectX 11 API for most of my needs and a somewhat fair understanding of OOP I want to start
designing a render loop (short of calling it game loop since there's no AI or physx yet) around a more scale-able architecture that could ultimately grow into a game... That means separating responsibilities in different classes and decoupling what can be, and ideally have a render class rather than have objects draw themselves.
Mind you I'm still at rastertek tutorial level of understanding LOL and it's mostly how to connect all the dots that's difficult more so than each separate topic such as shadows, skyboxes, reflections, render to texture or what-have-you.
It's how games elegantly add creatures, remove them, iterate through them, draw them in the most optimal order etc that seems to be the crux of videogame development imho. I believe this article pretty much hits the nail on the head and draw call sorting might make everything fall into place...
Now initially that sounded weird... sorting "function calls" ?!? lolwut? but of course it's the data that has to be rendered that's sorted by renderstate. Fine. Now in the article they mention "using standard sorting algorithms" and "key/value" pairs. That to me screams std::map but is this what is usually used by professionals? I tried a bit of dummy example code with std::map to see how fast it is and it appeared that even iterating through a couple of entries on my i5 laptop with 256 kb of cache takes a couple of milliseconds, an eternity when you've got only 16 ms per frame and you are supposed to iterate 2000 draw calls. I admit I haven't tried to actually sort 2000 entries as I had to come up with 2000 things to fill it with but could it be that it won't take much longer as some of this time was overhead? Or is std::map just not the right solution? What I liked about it is that it's actually automatically sorted but maybe some unordered map followed by a sort is better? (then again my measurement was done for iterating only, after I had inserted values so the timing would even be worse otherwise)
Maybe my measuring tool wasn't appropriate? I used "time.h" clock() like so:
//iterate std::map with barely 6 key/value pairs in it
cout << t <<endl;
I know there are higher resolution timers out there but since we're talking milliseconds here I guess I'd measure the same. Now if it's simply an inaccurate tool I'll reconsider...