GBuffer.net

Well, it's been a long time since I have added anything more than pictures to my blog.

A lot has happened since I first started this blog.

The most important realization being that my old programming style is utterly junky.
The main problem is that I always sit down and start coding without any design and planning what so ever. And finally when I hit a road block I change the code. In fact the engine that I wrote went through so many changes, it's impossible to say it follows any solid programming style.
To a large extent I knew my programming style was quite crappy, but just didn't know any alternate way. I was always against C++ inheritance and was always for a static program structure, but really didn't know any proper implementation technique. Luckily for me, I discovered a whole new world of templates. Boy are they great!!! I think inheritance should be left at college level just so that we pass our exams.
Anyway this means that my precious project is a whole pile of binary junk. And now I have to start over. Oh well. Better late than never.
And then I learn that a whole bunch of other techniques are actually a big no-no. Some of which I am still quite hesitant to give up.

Luckily for me I met a really talented guy and he explained some good programming practices and I soon realized I was breaking most of them. There are one or two I don't agree with him on, but those don't make such a big difference in any case IMHO. On the other hand I was quite happy to realize that my basic priciples like having static code and getting the compiler to do as much work for me were the best principles to follow. It's just that I had no idea or techniue of how to do these things. (I'm actually making excuses for bad programming here)
I plan to write out the good programming practices that were told to me, so that everyone can start writing better code in future.

I also seem to have a decent amount of exposure to Unreal Engine 2.0 and learned a lot of new tricks in the trade. One thing I was surprised to learn is how well they followed most/all the good programming practices. It's amazing. I always knew that they were doing it right. This also means that my precious project is junk overnight and I have to start over. I have no idea if I am going to and if so when. I am thinking of keeping it small and simple and making just a rendering framework to test shaders and other things I write. Besides I still have another project that I'd like to release. I really need to open this one up and see how badly it has been contaminated by my bad planning and poor programming practices.

Other than that I put up an article that I wrote a long time back. I tried submitting it to DevMaster.net and gamedev.net. Both still haven't put it even after nearly 6 months after initial submission was made. DevMater.net showed interest in putting it up strangely. I got tired of waiting and put it up on my own site. At least it is out there, and boy I am happy I did not put any code in to the article. In any case part 2 will be coming soon. Just need to get some formatting done on it.

When I first started coding the Replica framework, I wanted it to be the fastest meanest framework out there. Due to some misconceptions I used to spend hours and hours optimizing things like the Win32 message loop, write code in ASM. AT one point I even thought I'd write the entire engine in ASM, to get the most out of the CPU. I spent almost 2 months in R&D on optimal vector maths and matrix multiplication.

Looking back I now realize that these are not the things that define the speed of the engine. Yes, they are important, but not as important as an improved graphics technique. Coming to realize it now, writing the whole framework in ASM may have given me just 1 FPS more (if at all), where as a simple improvement in a graphics technique will give me much more than that. Not to mention the inconveniences that I would have to go though managing ASM code. Don't get me wrong, an optimized vector class is important, but something like this is fairly straightforward and definitly did not need months of R&D. Just run it through VTune and you will get the most optimized code in the world.

Everytime the latest Quake source code came out, I'd go running to the vector class and see how they did it… And then be majorly dissapointed. For a long time, I even though that they used to replace the actual optimized code and put in the lame C code in it's place. I was most dissapointed when I started writing a mod for UT2K4. I realized that they were doing vector normalization in the .uc scripts. Mahn, what were they thinking!!!

Now after reading several presentations, articles and looking at some of the world's best engines, I'd say there is a looong list of optimizations that are needed, but none of them are near the vector class or the Win32 message loop as these are something that we will never be able to change.

IMO, a major amount of time spent is used to shovel data in memory and out of it, and just by using memory wisely you can improve the performace of any engine. And be warned this is not just in the CPU. Data shoveling takes place even in the GPU. Just try switching on mipmaps and see what a huge improvement in speed you get.