Last week is a long week because lots of stuff happened which made the development process even harder, in another more tough and interesting.
1, The Frame buffer object. Also, we can call it render target. This technology can really speed up the rendering by using a texture or render buffer as an offline, which allow us to add some post effect on it, for example, glow effect, HDR tone mapping, DOF, etc. Therefore, this is the key component in the current rendering engine. Most of the time, we need to deal with Multiple Render Targets (MRTs), which is pretty tricky and require you to be clear which render target you are deal with, how and when to “activate and “restore” it. There are many sample codes online which are pretty good: http://www.g-truc.net/sample-ogl2.html, http://www.feedsfarm.com/article/ad25941ddd7038b6a25c3ab76a6144603487ee24.html
2, CgFx Material. No matter you are dealing with CgFx, GLSL, or HLSL, you need to have you own class to manage the shader framework and also, you need to take care of the performance issue or you scene will run extremely slow after integrating couples of shaders. You may ask why. Why? It is pretty common as you may know each pass in a shader need to setup its own rendering state, which cause lots of processing time for your GPU to switch between states. Here is the common solution: 1, sort your object by rendering state(material, effect, etc). 2, Set or Reset the state only when the same state group is finished rendering. 3, Optimize you framework to make sure the parameter setting call number is minimum. Because whenever you set a parameter of certain shader, you need to pass some variable from system memory to GPU memory, which is slow. In a word, cut the shader calls as less as you can.
3, Make sure you know what you are doing when coding. People are very careless these days when programming. I met a legacy bug from the system, which states in pixel shader of Shader Model 3.0, you can loop through an indexed array only when it is texture coordinate semantic and indexed by the loop variable. Like this kind of bug is not easy to fix because the algorithm is already fxied and the calculation need to be done in pixel shader, how can you avoid the looping? I didn’t come up with the perfect answer but we can unfold the looping and limit the maximum boundary of the loop, which means we limit the function of the shader if we have to fix this. Let’s think about the cause, why a bug like this will exist. If we can always pay attention to what you are writing rightnow, let say I am writing a PS 2.0 program and I need to stick with the profile spec of it. Also, after you program seems to work, we need to put some log or error checking when calling it to make sure there is no warning or error. I know, I know this will cost some time but it will save lots of people time and money to just find the bug, let alone to fix it.
4, Check the module related with what you have modified before hastily submitting your code. Make a fully test the corresponding module before telling others you just fixed a bug or create a new wonderful feature because this may be the beginning of a new regression. This situation happens a lot in new developers, even for some experienced programmers. People are easily ignore to testing all the related codes, instead, to submit the new changed code just because they think they spend some or a lot time on the development and finally it comes up with a nice result. However, the last path to success is always full of mines. If you don’t take care them, you may cause some serious trouble for yourself, even the entire development and QA team.
Above, it is my feeling during last week.