What I know about Computer Graphics

I've been working closely with CG both professionally and as a hobby for the past 5-6 years. I've been making games and developing engine architectures. Latest developments can be tracked on Claymore Dev blog. I've seen different techniques, tried many others, even written articles about them in big books (GpuPro-3, OpenGL Insights). And the funny point is: I still don't know how to build engines... All I know is how bunch of known techniques may help or screw you up, based on personal experience.

Uber-shaders
Problems: Difficult to maintain due to bad granularity and monolithic approach. Unable to extend from the game side.
Alternative: Shader compositing. In OpenGL you can extend the functionality by either linking with different shader objects, swapping the subroutines, or by directly modifying the source code.

Deferred shading
Problems: Very limited BRDF support. High fill-rate and GPU memory bandwidth load. Difficult to properly support MSAA.
Alternative: Tiled lighting. You can work around the DX11 hardware requirements by separating lights into layers (to be described).

Matrices
Problems: Difficult to decompose into position/rotation/scale. Take at least 3 vectors to pass to GPU. Obligation to support non-uniform scale (e.g. no longer skipping invert-transpose on a 3x3 matrix to get a normal matrix).
Alternative: Quaternions and dual-quaternions. Both take 2 vectors to pass.

Context states
Problems: Bug-hunting is difficult because of bad problem locality. Assumptions over the context are easy to make, but if you decide to check it with assertions, why not just pass the whole state instead?
Alternative: Provide the whole state with each draw call. Let the caching work for you.

C++
Problems: Memory management and safety. Compiler-generated copy operators/constructors. Pain dealing with headers and optimizing the compile time. Many many lines of code.
Alternative: Rust. Other "safe" languages (.Net family, Java, Python) are not as low-level and often trade performance for safety (i.e. global GC phase causes an unacceptable frame rate interruption).

All I actually know is that there is a thousand and one difficult architectural issues of the graphics engine, and there is no silver bullet to most of them. For the most common solutions I listed possible alternatives, but they are no near being flawless. I hope that one day the amount of experience I get will magically transfer into the quality of my decisions, and I will finally know the right answers.

OpenGL revenge!

When I started my gaming life, there were many competing graphics API created by software companies & hardware manufacturers:

• Direct3D (all: Microsoft)
• OpenGL (all: open standard, ARB group)
• Glide (3Dfx only)
• MeTaL (S3 only)

The last two performed very well, but only on the corresponding hardware. Unreal Tournament & Deus Ex where the best games to test all these render modes in action.

Time passed, and Glide & Metal silently died, leaving GL competing with D3D, having only a single guard: Id Software. I can only guess what would happened to GL at that time if there was no John Carmack (Id lead programmer)... S3 technology was bought my MS that spread S3TC wisdom all over the word.

OpenGL standard developed very slowly, but easy extension mechanism allowed programmers to use all the new features Direct3D contained, and even more. Microsoft performed a massive information attack on GL (see FUD) leaving only cross-platform games alive.

Now there is XNA, Win7 with its DX11 and hordes of MS fans lurking around with their XBox'es. Other camp primarily consists of Unix/Linux systems, Mac OSX and a bunch of smart embedded devices including PS3. As far as I see, the time of revenge has finally come!

OpenGL ES (at least 2.0) has a very successful design: simple, portable, effective. It was developed by Khronos group that is now pushing forward OpenGL-3 standard. Microsoft was not able to spread it's massive OS on mobile devices, and now we have numerous game-dev companies working on iPhone & PS3 games using OpenGL ES only. Moreover, Linux & Unix community grows: they might not be willing to pay for games, but they are developing exclusively on GL. At the same time, we have Mac OSX users that easily afford themselves buying games, forcing major titles being released for this OS (take Dragon Age for example).

The conclusion is: there is no point to develop your engine primarily for Direct3D unless you want to run on XBox. OpenGL successfully covers all other platforms (there is only a little difference between ES and normal GL nowadays), has a clear extensible design and an open standard. Congratilation, my friends, our victory is close! And the world will be a little better place to live soon :)

P.S. Some people say you don't have to choose and support both API anyway. That's true, but don't forget about the future: your choice may shift the balance in this fight giving an initiative to the hands we can't trust.