My Vision for a Successor to RenderMonkey and FX Composer

AMD RenderMonkey has always been my favorite shader prototyping tool. I've done tons of rendering experiments with it. Only weeks ago RenderMoney offered me a great helping hand when I did my research work on the topic of cel-shading. Unfortunately, AMD decided to discontinue the development of RenderMonkey in 2009, leaving us with a legacy version - v1.82, which is pretty stable, but only supports DirectX 9.0c and Shader Model 3.0. A Q&A here addresses that the main reason for this is RM's lack of ability to program CPU. Nvidia's counterpart to RM, FX Composer, though not officially announced, seems to be sharing the same fate of abandonment, as the latest version was released back in 2009, with only DX10 support.

Therefore some people demand a successor to these tools, with the latest technologies integrated (namely DirectX 11 and OpenGL 4). I am now seriously considering "go ahead and do it". In my vision, this new tool should:

1) Support the latest generation of graphics API: DirectX 11 and OpenGL 4.0. These standards have been out for years and are being put into practical use in real-world games and applications. There is simply no reason not to support them.

2) Add new shader stages (geometry shader, tessellation shaders). Not so long ago, when we say "shaders", we mean the pair of vertex shader and pixel (fragment) shader. But the world has changed now. DX 10 and OpenGL 3 introduced the concept of geometry shader, and we had tessellation shaders in DX11 and OpenGL 4. The new tool has got to embrace them if it wants to stay relevant.

3) Be able to expose its inner data structures and routines to user-created extensions. Both RenderMonkey and FX Composer suffered from the inability to write CPU code because not all effects can be done exclusively on GPU. If we can employ some mechanics to give users full control over its rendering pipeline by writing their own C++ plug-ins, like what you can do to 3ds Max with Max SDK, it will be a whole different world.

4) Have a friendly and powerful UI. IMHO RenderMoney has over-simplified UI and FX Composer has an overcomplicated one. A mixture of the two might be just right.

5) Build a platform for the users to share and showcase their works. This idea is inspired by the Shader Library shipped with FX Composer and the model of Unity's Asset Store. Package all your source materials of an effect (code, plug-ins, models, textures or even papers and docs), and share your brilliant work with the rest of the world. Wow, that'd be real cool...

Conviction is still a stealth action adventure

With Splinter Cell: Conviction, Ubisoft made a major tweak to the flavor of the franchise. Sam Fisher is no longer a Third Echelon filed agent, he has gone rogue and become more deadly. With no restriction on lethal force and no requirement to remain undetected, SC5 allows you to take out a good deal of intense action.

I once worried about this change. I watched some of the gameplay preview videos before its release and felt like Splinter Cell is being turned into a TPS. An entire line up of weaponry from Desert Eagle to M3 shotgun? Sam has never gained access to so many heavy and noisy weapons. They might as well add a RPG!

Oh, and they have a new cover system, which basically works the same way as an ordinary cover-based TPS. A cover provides 100% protection during a gun fight. You lean out the cover to shoot your enemies while they are reloading. You move from cover to cover to approach targets and gain tactical advantages.

However, while these ingredients sound very similar to a third-person shooter, the actual gameplay of Conviction is way different from Uncharted or Gears of War. After your first attempt to confront your foes with direct shootout, you'll find out that stealth action is still the rule of thumb in the world of Splinter Cell.

Ubisoft has done a lot to ensure that direct gun fight is a punishing way to eliminate the enemies. Firstly, Sam Fisher is as weak as before in terms of taking damage. In "Realistic" difficulty, 4 or 5 light weapon shots are sufficient to put you into the "near-death" state. Hit by a shotgun or a frag grenade explosion? Well, that's an instant kill. Secondly, enemies are extremely accurate. More often than not, when engaging multiple targets (that's 90% of the cases), you get shot every time you lean out from a cover. Also, AI is often quite aggressive. They will try outflanking you during combat. This is the most significant reason why direct gun fight is punishing in Conviction. You can hardly survive attacks from multiple directions.

By comparison, leveraging Mark & Execute or doing head shots without exposing yourself is far more comfortable. Being stealthy is still the correct action that the game designers encourage you to take. You may not be able to "ghost through" every level in SC5, but Sam Fisher is still more a shadowy ninja than a fearless berserker.

Why Does Every Game Programmer Want to be a Rendering Programmer

The vast majority of the programmers I've worked with, and myself also, all have a strong interest in 3D programming. If their job title happens to be a Rendering Engineer, they often addict to their work; if not, they will seek for every opportunity to become one.

Not until recently did I raise a question to myself: why it is this case? Why does every game programmer want to be a rendering programmer?

These are my thoughts:

1. First and foremost, 3D programming is pretty bloody damn cool! Everyone has a love for gorgeous graphics, right? That's why they want to be one of the talented minds who make these eye candies.

2. They are tech geeks, and 3D technologies are often the most advanced technologies of a certain console generation.

3. We are proud to be game programmers, and the mastery of rendering technologies is one of the key differentiators between the skill set of a gamedev and the skill set of a traditional software engineer.

4. There are an abundance of learning resources in this field. Books, SIGGRAPH papers, GDC keynotes, you name it. 3D programming can be hard, but with so many research out there, you hardly get lost in tackling tough challenges.

How About Being English Only?

As blogspot.com is blocked from the majority of us PRC people, I decided to turn Memory Unit 1111H into an English-only blog. Though my English proficiency is far from being bilingual, I'm working hard to improve.

I liked the name Memory Unit 1111H, so I'm gonna keep it in this transition. I am a programmer. I was born on November 11th. That's why I came up with this name. Nice and simple. Regardless of the fact that we don't use 16-bit CPUs any more.

I will be posting here irregularly. The main topic is of course video game development, but not limited to the technical aspects. I've been in this industry for more than 3 years now. It's time for me to share some thoughts on this unique media we devoted ourselves to.