Changelog 26/Feb/2013

In late 2012 I announced a feature freeze. Then the winter hiatus came and those plans were scraped. Now I am somewhat back to that stage, not really a feature freeze, but a general cleanup and solidification for the library.

As an extra note I will be moving to pixel shader 3.0 for the parts that are needed. With pixel shader 2.0 there are increasingly more places where multipass would be needed and I really don't have the resources, especially time wise to maintain two different rendering paths.

So for these changelog posts I will be listing the changes that went in one by one. If there are still some issues left on the current bullet point, I will be listing them in bold. And as these issues get resolved, I will be updating posts, writing after the bold section with bold green/blue.

Changelog:

• Finished restructuring material resources on disk for the new free-form paradigm. Textures are now located under ${GAME_DIR}/data/textures. Models are under ${GAME_DIR}/data/models. There is also a default structure, but you can now use whatever to locate resources. A good convention helps though. Materials also have an ID, a string name that is somewhat like an variable name meant for humans to easily recognize the material.

Textures are really starting to eat a lot of space. Need to study all DXT & co compression methods and start using them.

• Started doing more with my spherical harmonics. The first thing I did was to give the world a dynamic tint. This will depend on the place in the world, time of the day, etc. For now take a look at the ambient lighting only (without normal mapping) for the engine:

And now let's see the full ambient lighting as the game uses it with the red tint:

What is missing from this picture? SSAO! hopefully I can add it during the next week.

• Implemented FXAA. Or under its technical name, "blur-X-blur-A-A". It is very blurry. I don't know if you want to combine traditional AA with FXAA, but the engine now supports even that and the results are even more blurrier. I don't like FXAA. The cynics among us call it a glorified blur. I looked over the algorithm and it is more than that, but the results are still the same. Why use it? It is cheap. Depending on you setup and needs, it can even be considered "free". It also has very poor temporal antialiasing especially with transparent textures. You can turn on FXAA on the fly. Here are two before/after shots:

While you can turn on FXAA on the fly, traditional AA is setup once before device creation so you can't change it on the fly. Need to implement this.

• Implemented SMAA. I think. Of course I am not reinventing the wheel and doing things like this from scratch. I take a demo with the reference implementation for the technique and integrate parts of it into my engine. This time the process was not that smooth. First I had problems compiling under debug mode, because the shader was complaining that it went over the pixel shader 3 instruction limit. The reference demo had no such issues. The second problem is that the number of render targets in engine and the flow from one to another is slowly getting out of hand. I had some troubles fitting in the SMAA render targets into the rendering pipeline. I hope it is good. The third issue was that it did not look as good as in the reference demo. I debugged and debugged but I couldn't fix it. Later, at the toilets, I had an Eureka moment. What if the content project from the demo has some extra flags in the project file. And it did. I found flags to make the shaders compile in debug mode. I also added some flags to the two images that are needed for SMAA and this improved somewhat the situation. Adding mipmaps also helped. I'm not sure if mipmaps are needed. The results are not 100% identical to the reference demo, but they are fine for now. I'll continue to investigate. Here is an image without AA:

Now with SMAA:

And finally the same in the reference implementation:

There is a small difference between the two samples. The quality of AA is pretty much identical, but the brightness is not the same. I'm curious what causes this. You can turn on SMAA on the fly, but not at the same time as FXAA.

When integrating SMAA I also had to use a few slightly overengineered content provider classes and logging classes. These must be removed and replaced with the solutions provided by the engine.

• Started moving classes from the game to the library/generic engine. The library has 119 KiB and 3200 lines of code. This is just a small fraction of how large it will be because most of the code is still in the game project. In the spirit of migration away from XNA it does not use the Content Pipeline or XNA Component class, that's why it is so big. About 2000 lines of code handle just DDS loading.

The library also has and attached content project for a few resources like shaders, but since I am inexperienced with solutions using multiple content projects, I couldn't get the to load from here. So temporarily the resources are in the game project. A few images and about 239 KiB of shader code.

• Gathered most settings that were all over the place in the game code into the GameSettings class that is now part of the library. Some settings are still missing, but here is the list of simple fields from the class: