Recently I have fortunately had a little time to sit and think, but very little time to code. This is a dangerous situation for code-crafting junkies, because we will begin to optimize and redesign everything that we don't like in our own weird way - the calendar, power waste, our shoelaces - but the actual physical creation that many people might realistically adopt from us, deservedly or not - our program - can become either an unkempt, piecemeal Frankenstein creature or merely an atrophied icon of a useful system. The situation does place a premium on efficiency, though. For this reason, it may become very exciting to read about some little thing that can be performed quickly to better our code, and that will retain its value and reusability.
Luckily, I ran across just such an article, written a couple of years ago by Nils Pipenbrinck (http://www.devmaster.net/articles/fixed-point-optimizations/). Pipenbrinck gives some good information on compilers and integer math (although in most cases there is really no need to use long integer casting as he does, and I don't know that CLZ-based looping for a square root on a 32b input argument would be worth the cost of overhead and unpredictable timing - minor questions).
Another recommendation is to visit the Dark Bit Factory, if you haven't (http://www.dbfinteractive.com/index.php). The showcase is fun, and I love that it gamuts everything from tight Asm to Basic. I will definitely be pulling a quick-shot idea from somewhere in that place. (I think I'm beginning to sound like Junie B Jones.)
I was also searching for some information from Jacco Bikker, who had written some handy bit-twiddling articles several years ago. I didn't find much, but did link from one of his tutorials to a 2001 survey paper on raytracing. The part that caught my attention was about progressive, corrective rendering:
"Recently, Haber et al have extended the approach to include perceptual information: This is used to focus the sampling effort towards perceptually important regions, thus getting visually pleasing images in less time. Corrective information is no longer stored in textures, but is splatted directly into the image. Here too, the image quality improves progressively as more and more corrective samples are computed..." (Wald & Slusallek, 2001)
It reminded me how little information really changes between each frame. If you take the average difference of two consecutive frames, I'd guess less than 5% of the graphic information has changed. Yet we render the entire scene again and again. There is so much our stereoscopic understandings pull out of small details in an image, so we cannot afford to mess them up. Additionally, each scene may be drawn with its own rendering scheme, constructed with its own primitives, and given its own special T&L, so it is difficult to define how we might conserve resources but still render a convincing 3D scene without redrawing everything in the window. All this caused me to reappreciate how nice interlacing really is for methods that can use it. It also inspired an experiment that I plan on trying out shortly.
