Quote:Original post by wolf As mike2343 says profile your code. What you also can do is remove all the speed bumps like STL (can't use it on consoles anyway)and BOOST and all the other things you do not want to use in game development. If you use C++ -it looks like it- reduce the number of virtual functions, use as much C as possible and don't forget that C is the language you will use most to program your renderer and especially SPU's and try to keep your code fast. Most modern engines are dealing mostly with data management. Depending on your underlying platform and the number of cores you will want to structure your C code following the data and not the other way around. So in essence do not think about designing classes but think about what you want to do with the data and see how you can stream data to the numerous stream processors on your hardware platform (GPU, SPU or multi-core CPUs). This is easier than one would think. If you know how to program a GPU you just build the same kind of model for some of the cores of a CPU. So you define a data input structure, a data output structure and you write small C functions that manipulate the data in-between. Than one of your cores works on this data ... I think you got the picture. So the idea is to distribute the work that the renderer does over several processors. When you program the GPU you will have to be careful not to re-build what the driver on the PC is already doing for you. Shadowing constant data might be a good thing to do. Managing render states so that you can set cache them too. Other than this I am not quite sure if you want to do anything special here. Because the GPU is the most powerful chip in your console or PC, you want to spend lots of time to figure out how to squeeze the last cycle out of it. On the C level you have the challenge to feed the GPU as fast as possible with data without involving shader switching, shader constant waterfalling, render state switches, texture switches and all the other terrible things that can happen here. Whatever you design on the C level is build in a way that you can feed the GPU in the best possible way. So your design is driven by the way you balance shader switching and all this other stuff while rendering.
In short, while you're busy rewriting mechanisms to do virtual functions, while you're busy debugging invalid void* to T* casts, while you're busy rewriting standard containers and algorithms, my code will be easier to verify as correct, and thus the designers can iterate on gameplay much earlier, and product risks can be evaluated much earlier, giving me more time to sit back and optimize intelligently, instead of debugging under the wire until ship.
Apologies for us completely going off-topic so back to your original post.
It's been pointed out that you could really do with profiling your code to actually find out what is costing you the most time. That string compares are bad, what's wrong with using enums? but that you're just fine using the STL and Boost.
However your question wanted to know about actual overhead which is considered normal. Which is a tricky stick to measure. If you're doing nothing particularly complex in terms of gameplay, no physics, little sound, etc then the renderer could take a large percentage of the available cpu time. Conversely if your doing a tonne of complex calculations (networking, physics, lots of 3D audio etc) then you're going to get bound by some hard cpu time limits and this will impinge upon the cycles you've got spare for rendering code.
Again it all comes down to profiling and eliminating your bottlenecks.
Andy
"Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile"
I'll see how much I can squeeze out by more aggressive optimizations - there are still a few heavyweights in the code, which is originally a prototype study.
I also wouldn't reject C++ at this point, since some of its abstraction facilities, esp. templates, are invaluable for me, being a single person who plans to implement tons of functionality quickly, bug-free, and with high run-time efficiency. Still, I think that this is not the right place to discuss these points.
Quote:Original post by RDragon1 In short, while you're busy rewriting mechanisms to do virtual functions, while you're busy debugging invalid void* to T* casts, while you're busy rewriting standard containers and algorithms, my code will be easier to verify as correct, and thus the designers can iterate on gameplay much earlier, and product risks can be evaluated much earlier, giving me more time to sit back and optimize intelligently, instead of debugging under the wire until ship.
I don't think wolf suggested at any point you try to roll your own virtual functions. I think he was suggesting that you simply try refactoring your renderer so that it requires fewer virtual functions in the back end. This is more important when developing on the currently generation of console hardware than you might think if you're only used to PC games programming.
To address your second point, I don't know of any large games company that hasn't rolled their own version of the the standard containers and algorithms. There are more savings there to be made than you might think (provided you know what you're doing). For example: eastl
Regarding the usage of C++ I always recommend Pete Isensee's talk on GDC. He is a bit generic so. As someone who writes a renderer you want to be more cautious.
Regarding the data-driven design you should read Mike Acton's GDC 2008 talk. He is a bit extreme in not using C++ at all but I can agree with most what he says otherwise.
Regarding balancing a game engine: if you are pixel shader limited and your game runs with 30 or 60fps you did a good job in using all your resources evenly. This is the ultimate goal :-) ... being CPU limited is not that good :-) but obviously easier to achieve :-)
