Project B - More On The Update and Post-Processing Framework

Published July 03, 2013
Advertisement

Engine Post-Processing Framework

I feel really bad about my last post. I feel like I made it too quickly and I did a poor job of explaining things. Because of this, I'm going to try to explain things a little better.I want to give more details of what is in the demo that I posted earlier. Though I talk a lot about the GUI, actually the first thing that I worked on was the post-processing framework. What is post-processing, basically with it, you can achieve all sorts of effects by running the entire completed scene through another set of shaders. You can use it to achieve effects like glow, motion blur, and many other things.

Here's an example of glow being created as a post-processing effect. From Genesis SEED, out IGF entry last year

saturn+sceenshot+small.png


This was the first system that I worked on because I wanted to fix a bug in it. I also wanted to design a really robust framework capable of handling many different kinds of effects.

How to do Post-Processing



The basic idea of post-processing is first render the screen to an auxiliary buffer instead of the back buffer. This auxiliary buffer can then be set as a texture to a shader. Then render a full screen quad of the texture using some effect shader. To perform different effects, you may need more than one auxiliary buffer. This is shown below.

post-processing+framework+1.png

The demo that I included in my last post used a glow effect. To perform glow, it uses the alpha channel to determine which areas should glow. The scene is first rendered to an auxiliary buffer. Then I use a 1/4 size buffer and render the entire scene to that buffer using a filter to only write pixels whose alpha value is set. Then I perform a vertical blur and then a horizontal blur. The final blurred texture is combined with the original image and then rendered to the back buffer. If you download the demo from my last post, you can take a look at the HLSL shaders.

Making a good post-processing framework isn't that hard. There's a good article on the subject here.

Some Cons



You have to be careful though. As you will be rendering the entire screen multiple times, you can lose a lot of speed. One way to speed things up is by using 1/2, 1/4 or even 1/8 size intermediary auxiliary buffers.

I hope this was useful. Check out my previous post to download the demo and see this and my GUI in action.

Previous Post:
Here are some screen shots.


ss1.png

ss3.png

ss2.png

2 likes 9 comments

Comments

Navyman

I like the information and screenshots, especially the space screenshot. Is that from your game or is it more of a test screen?

July 03, 2013 04:40 PM
Squared'D

The space screenshot is from our IGF entry last year. I really want to finish that game, but it was put on hold by another team member. It's too big of a project for me to do on my own so it's in limbo now. Project B is a different game, but it'll use a lot of the same source code. Unfortunately, the project just started and I don't have any screen shots yet.

July 03, 2013 10:30 PM
polyfrag

Did you make the GUI or did you use a library? Do you use FreeType or some bitmap font generator? How do you support unicode? Is it necessary to use the multi-byte character set or unicode character set option in Visual Studio?

July 04, 2013 06:58 AM
Squared'D
I wrote the GUI by myself except for the system config that uses DXUT. I haven't finished all of the controlsyet, but it works fairly well. I forgot to add a credit, but the for fonts, I used the font bitmap generator from AngelCode.com. Internally, the code uses wide chars for most things except when connecting with other librarieslike rapidxml. The AngelCode bitmap font generator can make all sorts of fonts in many differentlanguages. I think the multibyte option in visual studio defines how TCHAR is treated and how the built in string functions work. If you only use wchar_t or char, I don't think it helps. You'll need to use TCHAR and it's respective functions for those compiler options to make a difference. That may also change which version of the win API functions are called. In win32, there are wide char and ascii versionsof everythin. For example, there is a SetWindowTextAand SetWindowTextW. Depending on the compiler settings,it will use to prepocessor to make SetWindowText be one of those.
July 04, 2013 07:10 AM
polyfrag

wchar_t is 2 bytes on Windows, so doesn't that mean that not all Chinese characters are supported? Or are they just UTF-16 encoded using more than one character? Is it really ASCII or is it UTF8 encoded? I don't want to use wchar_t because it's a different size on Linux/Mac.

July 04, 2013 07:15 AM
Squared'D
They may actually be using UTF-16, which will use multiplebytes if the value goes to high, but I'm not sure. The most common languages will all fit in 16bits including Chinese and Korean. Some less common chinese glyphs may need more bits, but the most common ones don't. Actually in USC2 which is 16bit unicode,the language that uses the most space is Korean. It's because of the special way they combineletters into syllable blocks. You bring up an interesting point. I've done most of my work on windows and am comfortable with it. I need to think about other platforms more though.
July 04, 2013 08:43 AM
Squared'D
I also use my own string class that internally stores things as widw char but it can convert betweenchar and multibyte.
July 04, 2013 10:58 AM
Navyman

I primarily work on Apple computers and so I try to keep projects multi-platform. It is very tempting when developing on windows to only focus on windows because of the large installed user base.

Still there are gamers on a ton of different platforms.

July 04, 2013 06:36 PM
Squared'D
You are right. I need to be more multi-platformminded.I've been trying to do that with my latest code.
July 05, 2013 03:33 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement